Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54650 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31386 invoked from network); 17 Aug 2011 15:19:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Aug 2011 15:19:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.218.42 mail-yi0-f42.google.com Received: from [209.85.218.42] ([209.85.218.42:46098] helo=mail-yi0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1E/A1-20534-31CDB4E4 for ; Wed, 17 Aug 2011 11:19:47 -0400 Received: by yie19 with SMTP id 19so938295yie.29 for ; Wed, 17 Aug 2011 08:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=/TMjkbgrrrbd8u6jueHDskuMOlVeQNdAkpayhZx0TJg=; b=DuqAefdURJ1WK2J0KzRGQDtT8TBajMRxZNbZhWZsXiacJWE30iNLgk5A7rNwABfeGu mJ443gBtn8o8ylSWZchMaZnq/n9jcYF2ERkvr7k7t5Nu/L83IVbV2TBMzSQqIIgubwHh h51Oq8RA15ofk44qf+XF8REUoDDwtJLWme9bs= MIME-Version: 1.0 Received: by 10.236.173.106 with SMTP id u70mr3521741yhl.238.1313594384875; Wed, 17 Aug 2011 08:19:44 -0700 (PDT) Received: by 10.147.41.9 with HTTP; Wed, 17 Aug 2011 08:19:44 -0700 (PDT) Date: Wed, 17 Aug 2011 17:19:44 +0200 Message-ID: To: Moriyoshi Koizumi , PHP internals Content-Type: text/plain; charset=ISO-8859-1 Subject: types conversion mistakes in cli's server From: pierre.php@gmail.com (Pierre Joye) Hi There are many loosely conversions in the CLI web server. Mostly from (u)int64 to size_t (on 32bit platforms) or in64t to char, or the other way 'round. What was the goal to support 64bit data range for content length (or read data) in 32 bit environments? If LFS support was the goal, it could be possible to make it server large files but the way it is now won't work. Any objection if I change it to use exclusively size_t to avoid any possible issues? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org