[PHP-CVS] svn: /php/php-src/branches/ PHP_5_2/configure.in PHP_5_2/ext/standard/file.c PHP_5_2/main/SAPI.c PHP_5_2/main/SAPI.h PHP_5_2/main/rfc1867.c PHP_5_3/configure.in PHP_5_3/ext/standard/file.c PHP_5_3/main/SAPI.c PHP_5_3/main/SAPI.h PHP_5_3

Issue solved, the patch has been reverted by Andrei, thanks.

However the question about the bad new configure option remains.

hi,

CCing Ilia and Johannes as Andrei "discussed with the RM offline", I
suppose it is Ilia, but Johannes is the 5.3 RM.

For the record, this fix is about using size_t in the SAPI to fix
issues with uploaded files > 2G.

While wondering what was the reasoning behind this commit, I came to
the conclusion that we should not do such thing in stable branches and
we should respect something we decided long time ago, to stop to add
bad options which can break PHP ABI or BC in one way or another. It is
especially important as we all know how distributors tend to deal with
such options.

The other reasons why I would like to revert this commit are:

• not sure there are so many people uploading 2G+ files
• 5.2 should really be in security fixes mode only
• 5.3 should be in bug fixing mode only (without ABI breaks, even optional :)

Opinions?

Cheers,

andrei                                   Thu, 18 Mar 2010 21:07:38 +0000

Revision: http://svn.php.net/viewvc?view=revision&revision=296358

Log:
Fix a few problems with large (2G-4G) file uploads. Added
--enable-large-uploads-fix switch because one change was in SAPI.h structure.

Changed paths:
   U   php/php-src/branches/PHP_5_2/configure.in
   U   php/php-src/branches/PHP_5_2/ext/standard/file.c
   U   php/php-src/branches/PHP_5_2/main/SAPI.c
   U   php/php-src/branches/PHP_5_2/main/SAPI.h
   U   php/php-src/branches/PHP_5_2/main/rfc1867.c
   U   php/php-src/branches/PHP_5_3/configure.in
   U   php/php-src/branches/PHP_5_3/ext/standard/file.c
   U   php/php-src/branches/PHP_5_3/main/SAPI.c
   U   php/php-src/branches/PHP_5_3/main/SAPI.h
   U   php/php-src/branches/PHP_5_3/main/rfc1867.c

--
PHP CVS Mailing List (http://www.php.net/)

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

While wondering what was the reasoning behind this commit, I came to
the conclusion that we should not do such thing in stable branches and
we should respect something we decided long time ago, to stop to add
bad options which can break PHP ABI or BC in one way or another. It is

or maybe at least queue it up in a branch for "BC breaking review", or in
a branch where the ABI has already changed? I.e. if at some point you
must break the API/ABI, you can then shuttle in the rest of the changes
that you would have wanted but had deferred for this reason.

especially important as we all know how distributors tend to deal with
such options.

well... it's not like we go making such changes just for the heck of it
you know. it's just that keeping cross-distro binary compatibility isn't
really a high priority for most open source projects, and it wouldn't
be for PHP except for certain non OSS products that depend on it :)

but i'm not arguing against the principle of your argument, though. just
making some armchair suggestions/commentary.

sean