Having run into this issue recently, here's a patch (hopefully attached,
mail.app and list filters willing) against PHP 5.3 to address it.
This patch will promote to double the file sizes that overflow LONG_MAX,
which works transparently for my script.
Note that this only touches the obvious func
On Wednesday 17 October 2007 09:13:03 am Stanislav Malyshev wrote:
> Of course. If there are two different PHP versions with different API
> numbers, it's OK. What's less OK is when there's two PHP builds with
> same API numbers which are binary incompatible.
right.
> > in the context of running
but this wouldn't be any different from any other api/abi bump. furthermore,
Of course. If there are two different PHP versions with different API
numbers, it's OK. What's less OK is when there's two PHP builds with
same API numbers which are binary incompatible.
in the context of running d
hi stanislav,
On Wednesday 17 October 2007 02:08:06 am Stanislav Malyshev wrote:
> > yes, this is of course a big deal for some people, esp if you're using
> > proprietary software that's built against the "original" abi. of course
> > if you're only using OSS extensions, you can simply recompile
On Tuesday 16 October 2007 04:37:57 pm Wez Furlong wrote:
> PHP's native integer type is long, how else are you going to relay
> numbers longer than a long back to the script without rewriting the
> engine to add additional integer types, which is a massive changeset?
okay, chalk this up to my IAN
yes, this is of course a big deal for some people, esp if you're using
proprietary software that's built against the "original" abi. of course if
you're only using OSS extensions, you can simply recompile them against the
new api/abi and there's no drawback.
That's not only about OSS vs. prop
You might have a point there; I'd assumed that CFLAGS made it through
to php-config, but it doesn't look like they do.
It should be a simple matter to define them in php_config.h instead.
--Wez.
On Oct 16, 2007, at 6:16 PM, Stanislav Malyshev wrote:
Yes, the patch does that; it turns on LFS i
Yes, the patch does that; it turns on LFS in the headers, which promotes
the off_t and size_t types that are used by streams to the 64-bit
versions. This is the one liner in configure.in.
The other larger part of the patch is to make PHP functions capable of
returning and accepting numbers that
On Oct 16, 2007, at 2:44 AM, sean finney wrote:
i would suggest that anywhere where one is doing something with a
size or
offset and not using the posix size_t/off_t types should get such
changes.
and like i said, i don't see the motivation behind this extra step of
returning the size in d
hi,
On Monday 15 October 2007 07:41:11 pm Stanislav Malyshev wrote:
> I didn't dive yet too deep into the patch, but shouldn't it be fixed on
> stream level and not function level? I.e. there are a lot of functions
> using streams (including files) - would they support bigger files too?
i would s
On Oct 15, 2007, at 1:41 PM, Stanislav Malyshev wrote:
I didn't dive yet too deep into the patch, but shouldn't it be
fixed on stream level and not function level? I.e. there are a lot
of functions using streams (including files) - would they support
bigger files too?
Yes, the patch does
I didn't dive yet too deep into the patch, but shouldn't it be fixed on
stream level and not function level? I.e. there are a lot of functions
using streams (including files) - would they support bigger files too?
I also think that while using size_t is good, changing binary structures
might b
hi,
On Monday 15 October 2007 09:26:30 am Stefan Esser wrote:
> please keep in mind that compiling PHP with large file support breaks
> binary compatibility...
> One of the globals contain a "stat" struct that has different size for
> LFS or no LFS.
yes, this is of course a big deal for some peop
On Mon, Oct 15, 2007 at 09:26:30AM +0200, Stefan Esser wrote:
> Hi,
>
> please keep in mind that compiling PHP with large file support breaks
> binary compatibility...
> One of the globals contain a "stat" struct that has different size for
> LFS or no LFS.
More harmfully, it also changes the ABI
Hi,
please keep in mind that compiling PHP with large file support breaks
binary compatibility...
One of the globals contain a "stat" struct that has different size for
LFS or no LFS.
Stefan Esser
Wez Furlong schrieb:
> This bug has been open for a while:
> http://bugs.php.net/bug.php?id=27792
>
hi,
some non-php-dev comments in case they're helpful...
On Monday 15 October 2007 12:13:50 am Wez Furlong wrote:
> This bug has been open for a while:
> http://bugs.php.net/bug.php?id=27792
> Having run into this issue recently, here's a patch (hopefully
> attached, mail.app and list filters wi
This bug has been open for a while:
http://bugs.php.net/bug.php?id=27792
Having run into this issue recently, here's a patch (hopefully
attached, mail.app and list filters willing) against PHP 5.3 to
address it.
This patch will promote to double the file sizes that overflow
LONG_MAX, which
17 matches
Mail list logo
