Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:13449
Return-Path: <kingwez@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 40732 invoked by uid 1010); 22 Oct 2004 09:53:26 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 40649 invoked from network); 22 Oct 2004 09:53:25 -0000
Received: from unknown (HELO mproxy.gmail.com) (216.239.56.249)
  by pb1.pair.com with SMTP; 22 Oct 2004 09:53:25 -0000
Received: by mproxy.gmail.com with SMTP id w67so23956cwb
        for <internals@lists.php.net>; Fri, 22 Oct 2004 02:53:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=k2/CPLPs+/vrWGSJYSunP5Sh1oK+yTAyLQCq7Kq0XRqHbM+mB7HsUIBxXmrK4oSTlmCDWfZaxosU9gEV1IuE/EF4q7Cj9ZYeSlHEtrslBVtQ33IcnwKyktXgzvw0Tu/RTV35ALfuzURNa+VOzMUxwUAHtRgu4bPc567gbnVKAH4=
Received: by 10.11.119.19 with SMTP id r19mr300711cwc;
        Fri, 22 Oct 2004 02:53:25 -0700 (PDT)
Received: by 10.11.117.13 with HTTP; Fri, 22 Oct 2004 02:53:25 -0700 (PDT)
Message-ID: <4e89b42604102202533086a25d@mail.gmail.com>
Date: Fri, 22 Oct 2004 10:53:25 +0100
Reply-To: Wez Furlong <kingwez@gmail.com>
To: internals@lists.php.net
In-Reply-To: <20041022094508.GA9395@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <20041022062249.GA8983@redhat.com>
	 <4e89b426041022015310a5165f@mail.gmail.com>
	 <20041022094508.GA9395@redhat.com>
Subject: Re: [PHP-DEV] _FILE_OFFSET_BITS=64 considered harmful
From: kingwez@gmail.com (Wez Furlong)

On Fri, 22 Oct 2004 10:45:08 +0100, Joe Orton <jorton@redhat.com> wrote:
> On Fri, Oct 22, 2004 at 09:53:14AM +0100, Wez Furlong wrote:
> > What I planned to do with the streams API for 5.1 was define
> > php_stream_off_t to be a 64-bit type (regardless of LFS support),
> > adjust the API where it is needed, and handle the LFS stuff centrally,
> > using the transitional LFS functions you mentioned if they are
> > present.
> 
> The difference in that approach is that you introduce a bunch of new
> error cases on platforms *without* LFS support, where you'd have to
> check for passing an out-of-range 64-bit php_stream_off_t value to a
> function taking a 32-bit off_t.  I think using php_stream_off_t = off_t
> or off64_t as appropriate is simpler for that reason.

I think it is important to force the size of the type, because we need to
be aware of the size of the type when passing it to/from zvals.
I'm happy with checking the range for non-LFS platforms,
as this should have minimal impact compared to the cost of actually
operating on the descriptor, and helps us to standardize on the API.
 
> But both approaches are feasible, the important thing is to avoid using
> -D_FILE_OFFSET_BITS=64, which just breaks so much.

OK, so we should roll back Edins patch from all branches and wait for
a safer fix.

--Wez.