Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54674
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4vsjpgYwqgV_gnX7GiZGjDGACstLsjk+mWQ5WRn9SmmQ@mail.gmail.com>
References: <CAEZPtU4vsjpgYwqgV_gnX7GiZGjDGACstLsjk+mWQ5WRn9SmmQ@mail.gmail.com>
Date: Thu, 18 Aug 2011 11:16:24 +0200
Message-ID: <CAEZPtU6Lo=TiPD3YV_kuvnWRfeexrvGiYUXM6R8GCcKbFyen6g@mail.gmail.com>
To: Moriyoshi Koizumi <moriyoshi@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: types conversion mistakes in cli's server
From: pierre.php@gmail.com (Pierre Joye)

done in r315128

On Wed, Aug 17, 2011 at 5:19 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> 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
>



-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org