[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
Stas, does this problem still persist for you? On 19 August 2013 22:05, Michael Wallner m...@php.net wrote: On 19 August 2013 00:01, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Listening on http://localhost:8964 Document root is /home/smalyshev/php-src/sapi/cli/tests Press Ctrl-C to quit. Quite strange... Why is the server's output shown here? I don't know, but this is what happens with this test, so it needs to be fixed. Yeah, well, for you, but not for me, so I'm not sure what to fix. -- Regards, Mike -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Always set return_value_ptr?
On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Is there any particular reason why we only pass return_value_ptr to internal functions if they have the ACC_RETURN_REFERENCE flag set? Why can't we always provide the retval ptr, even for functions that don't return by reference? This would allow returning zvals without having to copy them first (what RETVAL_ZVAL does). Motivation for this is the following SO question: http://stackoverflow.com/q/17844379/385378 Patch for this change can be found here: https://github.com/php/php-src/pull/420 The patch also adds new macros to allow easy use of this feature called RETVAL_ZVAL_FAST/RETURN_ZVAL_FAST (anyone got a better name?) If no one objects I'll merge this sometime soon. Nikita
[PHP-DEV] PROPOSAL: temp stream for post_data
Hi, I prepared a patch to replace sapi_globals' request_info post_data and raw_post_data with a temp stream and remove support for HTTP_RAW_POST_DATA. [1] PROS: * save up to 300% on post_data_len memory (on non-form POSTs) * a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative) performance impact; see attached logs * reusable php://input stream * ... CONS: * no more $HTTP_RAW_POST_DATA, where BC could easily provided with a one-liner: $GLOBALS[HTTP_RAW_POST_DATA]=file_get_contents(php://input); * memory is cheap * ??? [1] https://github.com/m6w6/php-src/compare/slim-postdata-merge -- Regards, Mike logs.json Description: application/json -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Always set return_value_ptr?
On Tue, Aug 27, 2013 at 11:40 AM, Nikita Popov nikita@gmail.com wrote: On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Is there any particular reason why we only pass return_value_ptr to internal functions if they have the ACC_RETURN_REFERENCE flag set? Why can't we always provide the retval ptr, even for functions that don't return by reference? This would allow returning zvals without having to copy them first (what RETVAL_ZVAL does). Motivation for this is the following SO question: http://stackoverflow.com/q/17844379/385378 Patch for this change can be found here: https://github.com/php/php-src/pull/420 The patch also adds new macros to allow easy use of this feature called RETVAL_ZVAL_FAST/RETURN_ZVAL_FAST (anyone got a better name?) If no one objects I'll merge this sometime soon. After discussing this point, I'm +1 with this patch. Julien.Pauli
[PHP-DEV] crc32() and ip2long() return values
Dear list,
I recently ran into big problems with crc32() and ip2long() both of which I
was using in the same codebase.
I know these issues have been debated at length in the past, but this
really needs to be fixed.
Anytime you persist these values (to any external medium, files or
databases) you're sitting on a time bomb.
I realize some of you have countless technical arguments why these
functions work as they're supposed to, but php is a high-level language,
and these functions do not work consistently across platforms.
It can't be the developer's responsibility to write unit-tests for
return-values on internal functions - nor should we need to write elaborate
wrapper-functions for these functions to get them to work consistently.
There are dozens (if not nearing 100) different user-land solutions to this
problem, so it's not like the need isn't there - anyone who has ever used
these functions probably needed a work-around. The need for an enormous red
WARNING label, and elaborate explanation on the crc32() documentation page
says it all - nothing this simple, that has been standardized for this
long, should require an elaborate explanation, complicated work-arounds or
for that matter a lot of thought on the developer's side.
Since a signed 32-bit integer value is the lowest common denominator,
that's what the functions ought to return, so that at least the return
value is consistent across platforms, and you can decide (for example)
whether to persist it to a signed or unsigned INT in a database, and except
it to work the same everywhere. (Databases at large, and at least MySQL,
correctly persists either signer or unsigned INT values across platforms.)
The simplest work-around I have been able to come up with so far, is this:
var_dump(unpack('l', pack('l', ip2long('255.255.255.0';
var_dump(unpack('l', pack('l', crc32('123456789_00_0';
Forcing the value into smaller (on some platforms) 32-bit integer, and then
unpacking it, provides a consistent value on 32-bit and 64-bit systems, and
on Windows.
Of course there is backwards compatibility to consider for this broken
behavior, so I propose the simplest solutions is to just add a new pair of
replacement functions. You don't need to deprecate the existing functions,
because they work as prescribed, however useless they may be for any
practical applications.
The new functions and backwards compatible implementations for older
versions of php might look like this:
/**
* @param string
* @return int a signed (32-bit) integer value
*/
function ip2int($ip_string) {
return unpack('l', pack('l', ip2long($ip_string)));
}
/**
* @param int a signed integer value
* @return string
*/
function int2ip($ip_int) {
return long2ip($ip_int);
}
/**
* @param string
* @return int a signed integer value
*/
function crc32i($string) {
return unpack('l', pack('l', crc32($string)));
}
int2ip() would just be an alias for long2ip().
I spent almost a full day fighting with these functions and testing
work-arounds, and I bet every php developer who encounters a need for one
of these functions will some day sooner or later go through the same.
Userland solutions are not solutions to fundamental problems that affect
everyone who uses the functions.
Arguing that this behavior is correct by some technical definition, is
futile - the behavior is problematic for practical reasons, so technical
circumstances don't really matter here. Core functions need to actually
work consistently and predictably for as many users as possible -
optimizing for C developers and people with deep technical knowledge of
operating system and compiler specifics does not make sense for a language
like php.
Please look for reasons to agree rather than disagree out of spite.
As said, I know this has been debated at length in the past, and always
with the same outcome - but the simple fact is that these functions don't
work for the end-users, and they do not provide proper cross-platform
support.
No one cares how integers work internally, in C, in the CPU, or in the VM,
and it's not relevant.
There is no need to put anyone through all this unnecessary hardship.
These functions need to work **for php developers**.
- Rasmus Schultz
[PHP-DEV] Pull requests report (27/8/2013)
Hi, I'm please to say that we keep processing the requests faster and faster, leaving only few not handled in their first week. Thanks for everyone who helped. New: #420 https://github.com/php/php-src/pull/420 Always provide retval ptr #421 https://github.com/php/php-src/pull/421 Dedicated syntax for variadic parameters Merged requests: #197 https://github.com/php/php-src/pull/197 fputcsv improvements to allow RFC 4180 compliance #237 https://github.com/php/php-src/pull/237 Fix DateTime, when use it with D/l in format and textual day have dot at the end #322 https://github.com/php/php-src/pull/322 Fix DateInterval-days value #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #417 https://github.com/php/php-src/pull/417 Stricter libc-client symlink check #419 https://github.com/php/php-src/pull/419 Test extension xmlrpc encode type double and string decode type string and int Closed requests (without merge): #418 https://github.com/php/php-src/pull/418 Add test for #65499 (not a PHP bug) Still open (21 days): #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan On Thu, Aug 22, 2013 at 2:24 AM, Lior Kaplan lio...@zend.com wrote: (reporting about two weeks) Merged requests (past 7 days): #359 https://github.com/php/php-src/issues/359 PHPTests for the DOMDocument::load and DOMDocument::loadXML #360 https://github.com/php/php-src/pull/360 Bug44168 #381 https://github.com/php/php-src/issues/381 Fixed #65225: PHP_BINARY incorrectly set #395 https://github.com/php/php-src/issues/395 typofixes - code related #402 https://github.com/php/php-src/issues/402 make the bison version check a blacklist #403 https://github.com/php/php-src/issues/403 Fix #61345: fix install of CGI binary #404 https://github.com/php/php-src/issues/404 php.ini-development/production: remove php_zip.dll #405 https://github.com/php/php-src/issues/405 Fixbug: phpize --clean will delete include/*.h #410 https://github.com/php/php-src/pull/410 Fix for php bug #64802 #411 https://github.com/php/php-src/issues/411 Use pkg-config to detect iodbc #412 https://github.com/php/php-src/issues/412 Create test to the extension xmlrpc, encode array and int. Closed requests (without merge): #325 https://github.com/php/php-src/issues/325 Add schema default/fixed value support in DOM (merged in April, closed now). #329 https://github.com/php/php-src/issues/329 Allow major versions of bison (done as part of #402). New: #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #414 https://github.com/php/php-src/pull/414 Fix #65483: quoted-printable encode stream filter incorrectly encoding #415 https://github.com/php/php-src/pull/415 Remove duplicate calls to set filename lineno for the DTRACE_FUNCTION_ENTRY/RETURN cases #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity Kaplan
Re: [PHP-DEV] PROPOSAL: temp stream for post_data
On 27-08-2013 14:08, Michael Wallner wrote: Hi, I prepared a patch to replace sapi_globals' request_info post_data and raw_post_data with a temp stream and remove support for HTTP_RAW_POST_DATA. [1] PROS: * save up to 300% on post_data_len memory (on non-form POSTs) * a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative) performance impact; see attached logs * reusable php://input stream * ... CONS: * no more $HTTP_RAW_POST_DATA, where BC could easily provided with a one-liner: $GLOBALS[HTTP_RAW_POST_DATA]=file_get_contents(php://input); * memory is cheap * ??? I think it's generally a good idea, but I have some concerns: * The whole point of PG(enable_post_data_reading) is to be able to read the input of the fly. If I read your patch correctly, the data is completely gobbled when you open php://input and then the temp file is reminded. This will result in a serious performance degradation on large inputs, as processing can only start after everything has been read. The behavior should be different if PG(enable_post_data_reading) is false. * I don't see SG(request_info).request_body being closed anywhere. Is this relying just on auto-cleanup? I recall that being problematic in debug mode unless you use php_stream_auto_cleanup(). * The php://input streams simply forward the calls to SG(request_info).request_body, so if you open two, the per-stream cursor position may not match the position of the wrapped stream (even if it matched, we wouldn't want one stream to affect the position of the other). I don't see any easy way out here; all I can think of is is duping the file descriptor for the temporary file in these situations. But then the book keeping for php://input would be more complicated. * The cast added php_stream_get_resource_id() seems unnecessary; may hide bugs. If you just want to be able to pass void* values, better to put an inline function there with a php_stream* parameter, that way you would have a compiler warning if you passed anything but a php_stream* or a void* (though this would break taking a pointer). -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
