I've revised my patch and linked to it for review.

Some notes:

Joe Orton commented that many libs are built without LFS, and those
that expose APIs that use off_t, struct stat and struct dirent will
suffer an ABI break if PHP forces those flags on, because the sizes of
those types will change.

The strategy that this revised patch takes is to determine if the
system supports the transitional LFS APIs (which are functions like
open64, stat64 and so forth) and based on that determination define
some php types:

- php_stream_off_t - an LFS capable version of off_t.
- php_stream_stat_t - an LFS capable version of struct stat

The streams API has been adjusted to use these types instead of the
regular system types.
The streams layer already has a portable representation of dirent, so
no new type for that is required.

The streams functions have been adjusted to use the transitional
functions when they are present, and returns values that overflow
LONG_MAX as doubles. (If we had large integer support, this would be
a fine place to use it).

- The patch does not allow > LONG_MAX values to be passed in,
however. In particular, this affects fseek(), so you will not be able
to seek to an absolute position with an offset > LONG_MAX. This is
not impossible to do, I just didn't get around to it--you need to be
able to accept both double and long values in the affected function(s).

The scope of this patch is limited to the streams layer; so there are
two things to note:

- any other callers of the streams functions should be checked to make
sure they are using the php_stream_off_t type in place of off_t.
Streams already uses its own type to represent struct stat, so this
type need not be explicitly checked, however, the use of members of
the stat structure should be reviewed to make sure that it handles the
increased bitness.

- the vcwd layer has not been touched by this patch, because it uses
the system types and there is potential for breaking the callers if we
naively change the function prototypes--which is exactly the problem
we're trying to avoid by not just building the whole thing with LFS

Lastly, the only 32-bit linux machine that I have hanging around to
test this on won't build php6 (not without taking the day to level it
up), so I've only tested this on 64-bit linux... which isn't a
terribly good test since it is natively LFS aware. It should also
work on Solaris.


[1] http://news.php.net/php.internals/32767 - original patch
[2] http://bugs.php.net/bug.php?id=27792 - main bug report
[3] http://www.php.net/~wez/lfs.diff - current patch

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
postedJun 14, '09 at 3:07p
activeJun 14, '09 at 3:07p

1 user in discussion

Wez Furlong: 1 post



site design / logo © 2022 Grokbase