[PHP-DEV] PHP6 - x64 SegFault
Hi, I'm new to the newsgroup and I'm trying to debug PHP 6 on a test server (x64 architecture). However, for some unknown reason, it segfaults if I try to run it with any files that work in PHP 5.2.0. The segfault is at the end of most scripts, at the beginning of others. The backtrace looks like this: #0 _zend_mm_free_int (heap=0xb30330, p=0x377cff39f390d7e) at /root/php6/Zend/zend_alloc.c:1522 #1 0x006a5cdf in destroy_op_array (op_array=0x2ab2aef29ff8) at /root/php6/Zend/zend-opcode.c:265 #2 0x006b06d5 n zend_execute_scripts (type=8,retval=, file_count=3) at /root/php6/ZendSend.c:1665 #3 0x00662763 in php_execute_script (primary_file=0x7bb9d360) at /root/php6/main/main.c:1949 #4 0x0073d1c4 in main (argc=2, argv=0x7bb9f5c8) at /root/php6/sapi/cgi/cgi_main.c:1656 This looks like a Zend issue trying to clean up after the running of a program. Can somebody please find a fix? I'm willing to test a patch first before it is committed. Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.2.1RC4 Released
The final release candidate for PHP 5.2.1, RC4 is now available for download. Pending any problems this will be released as 5.2.1 next week, so this is the last chance to identify any critical issues before it is too late. If you have not tried any previous RCs, please do so now. The tar balls can be found at the URLs below and win32 binaries will follow shortly. http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum: f50578276f653b1f523150e3ff987f03) http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum: 361197eb2b21b36e2e20cb132da2cf16) I'd like to ask all developers to refrain from making any (no matter how trivial) commits to the 5.2 branch until 5.2.1 is released, if you feel you have a critical patch, please run it by me first, thanks. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
I've been thinking about how to not force UTF-8 in PCRE for PHP 6, and it's not that simple. This is mainly due to preg_replace(), because it allows array() parameters that can contain mixed IS_UNICODE and IS_STRING values. I hope you realize though, that in UTF-8 mode PCRE does not care about POSIX locales, even in PHP 5. I haven't though on that, but can't you simply reject mixing of unicode and binary strings? By the way, I think ICU regexp extension, when implemented, will let you match Portuguese characters in UTF-8 strings. I wasn't aware of that API.. anyway it is probably slower than pcre+locales (because it uses unicode propertie table lookups) Yes, UTF-8 covers many aspects but does it know about words, white spaces (not sure if ws are always the same) and other locale specific issues? generally, not only pcre. Maybe it is more something for ICU directly, as you said later in this thread. That's not really a problem with pcre, as it supports unicode character properties. It isn't documented in phpdoc (don't look at me :P), but it looks like: \pL where L is one of (from http://pcre.org/pcre.txt): L Letter LlLower case letter N Number NdDecimal number NlLetter number NoOther number P Punctuation ZsSpace separator (...) Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
Please do not confuse an encoding (UTF-8) with full locale information (which is what CLDR provides). -Andrei On Jan 25, 2007, at 10:20 AM, Pierre wrote: On 1/25/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: Because with UTF-8, PCRE already knows the uppercase and lowercase equivalents, without having to rely on the POSIX locales. Yes, UTF-8 covers many aspects but does it know about words, white spaces (not sure if ws are always the same) and other locale specific issues? generally, not only pcre. Maybe it is more something for ICU directly, as you said later in this thread. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 1/25/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: Because with UTF-8, PCRE already knows the uppercase and lowercase equivalents, without having to rely on the POSIX locales. Yes, UTF-8 covers many aspects but does it know about words, white spaces (not sure if ws are always the same) and other locale specific issues? generally, not only pcre. Maybe it is more something for ICU directly, as you said later in this thread. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
I've been thinking about how to not force UTF-8 in PCRE for PHP 6, and it's not that simple. This is mainly due to preg_replace(), because it allows array() parameters that can contain mixed IS_UNICODE and IS_STRING values. I hope you realize though, that in UTF-8 mode PCRE does not care about POSIX locales, even in PHP 5. By the way, I think ICU regexp extension, when implemented, will let you match Portuguese characters in UTF-8 strings. -Andrei On Jan 25, 2007, at 9:07 AM, Nuno Lopes wrote: But how do I match only portuguese letters? you'll (always) need posix locales.. I don't think forcing preg_* function to utf-8 is a good idea, but anyway I haven't looked enough to PHP 6 (yet) to produce a strong opinion. Nuno Because with UTF-8, PCRE already knows the uppercase and lowercase equivalents, without having to rely on the POSIX locales. -Andrei On Jan 25, 2007, at 7:24 AM, Pierre wrote: On 1/25/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: PCRE should operate in UTF-8 mode. How does UTF-8 help to make it locale compliant? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] COM extension defects: Possible patch for defect 35464
Hi Andy, I think this code and your explanations look good. I'll give the patch a run tonight when I get home but I do not see any problems with it. - Frank > Hi Internals > Attached is a suggested patch for COM defect 35464 > (http://bugs.php.net/bug.php?id=34564) Any comments; good or bad welcome. > Regards > Andy > > Andy Wharmby > IBM United Kingdom Limited > Winchester, England SO21 2JN > E-mail: [EMAIL PROTECTED] > > COM defect 35464 > > > The following details 2 reasons why in/out parameters don't work; one > caused by a problem with tetscase another a defect in COM extension code. > The testcase supplied by the raiser implements the DWebBrowserEvents2 > interface to register an handler for the BeforeNaviagte2 event. This > handler is passed just one in/out parameter; a VARIANT_BOOL which can > be set to TRUE by the handler to cancel the navigation operation. > Doing so in PHP currently has no affect, for the 2 reasons I will > describe below, so the navigation completes and the specified page is > displayed by IE. > > Issue 1 > == > The users code is attempting to modify the variant directly in PHP code > as follows: > > $cancel = true; > > rather than using the COM method variant_set as follows: > > variant_set($cancel, true); > > With this correction to the PHP script in place the variant for $cancel > is correctly changed to TRUE but IE still navigates to the requested page > so the modification is having no effect. The reason for this is the > subject of issue 2 below. > > Issue 2 > == > When an event notification is received by the COM extension > disp_invokeex() processes the incoming parameters (variants) by taking > each one > and wrapping it in a php_com_dotnet_object object. At this time a COPY > of the incoming variant is embedded into the php_com_dotnet_object so we > immediately have 2 copies of the variant and it is this copy in the > php_com_dotnet_object which is processed (get and set) by the PHP code. > I see no code that checks for modification to our copy in the > php_com_dotnet_object before returning to the caller (in this case IE) > so modification > to in/out parameters by the PHP code has no affect. > > Given that the code copies an incoming variant in php_com_wrap_variant() > I would have expected to see some code prior to return in disp_invokeex() > which checks for modifications to in/out parameters and copies any > modified values back to the callers copy of the variant. > > I have hacked some code as follows: > com_wrapper.c: http://www.pastebin.ca/328026 > com_variant.c: http://www.pastebin.ca/328022 > com_misc.c: http://www.pastebin.ca/328025 > php_com_dotnet_internal.h: http://www.pastebin.ca/328027 > > The new code works as follows: > (1) When a variant is modified by a call to variant_set() in > com_variant.c a new flag (obj->modified) is set in the > php_com_dotnet_object. > > (2) After a successful call to a event handler new code in > com_wrapper.c function disp_invokeex() checks each of the event > handlers arguments > (php_com_dotnet_object's ) to see if any of their embedded variants > have been modified. If so and the argument passed into the event handler was > passed by reference then the value in the embedded variant is copied to > the callers copy by a call to a new function php_com_copy_variant() > defined in com_variant.c. > > With this patch applied when the supplied testcase is run the navigation > is now cancelled as expected. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
But how do I match only portuguese letters? you'll (always) need posix locales.. I don't think forcing preg_* function to utf-8 is a good idea, but anyway I haven't looked enough to PHP 6 (yet) to produce a strong opinion. Nuno Because with UTF-8, PCRE already knows the uppercase and lowercase equivalents, without having to rely on the POSIX locales. -Andrei On Jan 25, 2007, at 7:24 AM, Pierre wrote: On 1/25/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: PCRE should operate in UTF-8 mode. How does UTF-8 help to make it locale compliant? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
Because with UTF-8, PCRE already knows the uppercase and lowercase equivalents, without having to rely on the POSIX locales. -Andrei On Jan 25, 2007, at 7:24 AM, Pierre wrote: On 1/25/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: PCRE should operate in UTF-8 mode. How does UTF-8 help to make it locale compliant? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] COM extension defects: Possible patch for defect 35464
Hi Internals Attached is a suggested patch for COM defect 35464 (http://bugs.php.net/bug.php?id=34564) Any comments; good or bad welcome. Regards Andy Andy Wharmby IBM United Kingdom Limited Winchester, England SO21 2JN E-mail: [EMAIL PROTECTED] COM defect 35464 The following details 2 reasons why in/out parameters don't work; one caused by a problem with tetscase another a defect in COM extension code. The testcase supplied by the raiser implements the DWebBrowserEvents2 interface to register an handler for the BeforeNaviagte2 event. This handler is passed just one in/out parameter; a VARIANT_BOOL which can be set to TRUE by the handler to cancel the navigation operation. Doing so in PHP currently has no affect, for the 2 reasons I will describe below, so the navigation completes and the specified page is displayed by IE. Issue 1 == The users code is attempting to modify the variant directly in PHP code as follows: $cancel = true; rather than using the COM method variant_set as follows: variant_set($cancel, true); With this correction to the PHP script in place the variant for $cancel is correctly changed to TRUE but IE still navigates to the requested page so the modification is having no effect. The reason for this is the subject of issue 2 below. Issue 2 == When an event notification is received by the COM extension disp_invokeex() processes the incoming parameters (variants) by taking each one and wrapping it in a php_com_dotnet_object object. At this time a COPY of the incoming variant is embedded into the php_com_dotnet_object so we immediately have 2 copies of the variant and it is this copy in the php_com_dotnet_object which is processed (get and set) by the PHP code. I see no code that checks for modification to our copy in the php_com_dotnet_object before returning to the caller (in this case IE) so modification to in/out parameters by the PHP code has no affect. Given that the code copies an incoming variant in php_com_wrap_variant() I would have expected to see some code prior to return in disp_invokeex() which checks for modifications to in/out parameters and copies any modified values back to the callers copy of the variant. I have hacked some code as follows: com_wrapper.c: http://www.pastebin.ca/328026 com_variant.c: http://www.pastebin.ca/328022 com_misc.c: http://www.pastebin.ca/328025 php_com_dotnet_internal.h: http://www.pastebin.ca/328027 The new code works as follows: (1) When a variant is modified by a call to variant_set() in com_variant.c a new flag (obj->modified) is set in the php_com_dotnet_object. (2) After a successful call to a event handler new code in com_wrapper.c function disp_invokeex() checks each of the event handlers arguments (php_com_dotnet_object's ) to see if any of their embedded variants have been modified. If so and the argument passed into the event handler was passed by reference then the value in the embedded variant is copied to the callers copy by a call to a new function php_com_copy_variant() defined in com_variant.c. With this patch applied when the supplied testcase is run the navigation is now cancelled as expected. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 1/25/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: PCRE should operate in UTF-8 mode. How does UTF-8 help to make it locale compliant? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
PCRE should operate in UTF-8 mode.
On 25-Jan-07, at 10:15 AM, Nuno Lopes wrote:
So are you saying that php will automatically issue setlocale() calls?
e.g.:
i18n_loc_set_default('pt_PT'); // or whatever that is called these
days
//now it magically calls setlocale('pt_PT', 'pt_PT.iso8859-1',
'portuguese'); -- linux/bsd/windows
echo preg_match('/^\w+$/', "àáãçêõ"); //prints 1?
?>
Nuno,
The idea is that while internal libs will use it, PHP will do all
the user-locale handling internally.
On 25-Jan-07, at 9:52 AM, Nuno Lopes wrote:
PHP needs locale insensitive strcasecmp() or your developers
will continue
hitting string comparison issues in Turkish and Azerbaijani.
Ilia patched
it in timezone parsing code. Some day other strcasecmp will
pop in other
place.
Switching locale everytime you want to compare strings is a
hack and not a
bug fix.
Its a solution that works. There are very few instances where
such behavior is needed and in php6 it won't be relevant anyway
since posix locales will not be used.
This is not true at all.. I even think this is a big
misconception of PHP 6.
Although this has nothing to do with the issue mentioned above,
we will still need setlocale() in PHP 6 because of externals
libs. Even the bundled PCRE uses locales, and that is very
handful (e.g. locale-dependent '\w'). So, POSIX locales will be
deprecated for string handling, date formatting and such things,
but they will still be used by external libs.
Nuno
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
So are you saying that php will automatically issue setlocale() calls?
e.g.:
//now it magically calls setlocale('pt_PT', 'pt_PT.iso8859-1',
'portuguese'); -- linux/bsd/windows
echo preg_match('/^\w+$/', "àáãçêõ"); //prints 1?
?>
Nuno,
The idea is that while internal libs will use it, PHP will do all the
user-locale handling internally.
On 25-Jan-07, at 9:52 AM, Nuno Lopes wrote:
PHP needs locale insensitive strcasecmp() or your developers will
continue
hitting string comparison issues in Turkish and Azerbaijani. Ilia
patched
it in timezone parsing code. Some day other strcasecmp will pop in
other
place.
Switching locale everytime you want to compare strings is a hack and
not a
bug fix.
Its a solution that works. There are very few instances where such
behavior is needed and in php6 it won't be relevant anyway since posix
locales will not be used.
This is not true at all.. I even think this is a big misconception of
PHP 6.
Although this has nothing to do with the issue mentioned above, we will
still need setlocale() in PHP 6 because of externals libs. Even the
bundled PCRE uses locales, and that is very handful (e.g.
locale-dependent '\w'). So, POSIX locales will be deprecated for string
handling, date formatting and such things, but they will still be used
by external libs.
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
Nuno, The idea is that while internal libs will use it, PHP will do all the user-locale handling internally. On 25-Jan-07, at 9:52 AM, Nuno Lopes wrote: PHP needs locale insensitive strcasecmp() or your developers will continue hitting string comparison issues in Turkish and Azerbaijani. Ilia patched it in timezone parsing code. Some day other strcasecmp will pop in other place. Switching locale everytime you want to compare strings is a hack and not a bug fix. Its a solution that works. There are very few instances where such behavior is needed and in php6 it won't be relevant anyway since posix locales will not be used. This is not true at all.. I even think this is a big misconception of PHP 6. Although this has nothing to do with the issue mentioned above, we will still need setlocale() in PHP 6 because of externals libs. Even the bundled PCRE uses locales, and that is very handful (e.g. locale-dependent '\w'). So, POSIX locales will be deprecated for string handling, date formatting and such things, but they will still be used by external libs. Nuno Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
PHP needs locale insensitive strcasecmp() or your developers will continue hitting string comparison issues in Turkish and Azerbaijani. Ilia patched it in timezone parsing code. Some day other strcasecmp will pop in other place. Switching locale everytime you want to compare strings is a hack and not a bug fix. Its a solution that works. There are very few instances where such behavior is needed and in php6 it won't be relevant anyway since posix locales will not be used. This is not true at all.. I even think this is a big misconception of PHP 6. Although this has nothing to do with the issue mentioned above, we will still need setlocale() in PHP 6 because of externals libs. Even the bundled PCRE uses locales, and that is very handful (e.g. locale-dependent '\w'). So, POSIX locales will be deprecated for string handling, date formatting and such things, but they will still be used by external libs. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 25-Jan-07, at 9:04 AM, Tomas Kuliavas wrote: PHP needs locale insensitive strcasecmp() or your developers will continue hitting string comparison issues in Turkish and Azerbaijani. Ilia patched it in timezone parsing code. Some day other strcasecmp will pop in other place. Switching locale everytime you want to compare strings is a hack and not a bug fix. Its a solution that works. There are very few instances where such behavior is needed and in php6 it won't be relevant anyway since posix locales will not be used. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On Thu, 25 Jan 2007, Tomas Kuliavas wrote: > Is it that difficult to replace strcasecmp with locale > independent case insensitive comparison function? > >>> > >>> We're open for patches. Feel free to send one. > >> > >> I am PHP developer and don't code in C. In PHP script locale > >> insensitive strtolower/strtoupper can be done with one preg_replace > >> call. > > > > Making PCRE a requirement for ext/date is not an option. > > > >> All timezone identifiers are written in plain US-ASCII. Lowercase > >> ASCII characters are in 0x61-0x7A range, uppercase characters are > >> in 0x41-0x5A. Maybe you can add 0x20 to all 0x41-0x5A byte values > >> and use strcmp() instead of strcasecmp(). > > > > Looks way overcomplicated comparing to the Ilia's solution. > > PHP needs locale insensitive strcasecmp() or your developers will > continue hitting string comparison issues in Turkish and Azerbaijani. > Ilia patched it in timezone parsing code. Some day other strcasecmp > will pop in other place. > > Switching locale everytime you want to compare strings is a hack and > not a bug fix. I actually agree there and it was one of the reasons why I didn't like this patch. However, it is the quickest way to do this for now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 01/25/2007 05:04 PM, Tomas Kuliavas wrote: Is it that difficult to replace strcasecmp with locale independent case insensitive comparison function? We're open for patches. Feel free to send one. I am PHP developer and don't code in C. In PHP script locale insensitive strtolower/strtoupper can be done with one preg_replace call. Making PCRE a requirement for ext/date is not an option. All timezone identifiers are written in plain US-ASCII. Lowercase ASCII characters are in 0x61-0x7A range, uppercase characters are in 0x41-0x5A. Maybe you can add 0x20 to all 0x41-0x5A byte values and use strcmp() instead of strcasecmp(). Looks way overcomplicated comparing to the Ilia's solution. PHP needs locale insensitive strcasecmp() or your developers will continue hitting string comparison issues in Turkish and Azerbaijani. Ilia patched it in timezone parsing code. Some day other strcasecmp will pop in other place. Switching locale everytime you want to compare strings is a hack and not a bug fix. I did not and I do not like it either, but it fixes the problem and does not introduce any new issues (anymore). If you think it's wrong and you have a better patch - send it to the list and we'll discuss it together. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
Is it that difficult to replace strcasecmp with locale independent case insensitive comparison function? >>> >>> We're open for patches. Feel free to send one. >> >> I am PHP developer and don't code in C. In PHP script locale insensitive >> strtolower/strtoupper can be done with one preg_replace call. > > Making PCRE a requirement for ext/date is not an option. > >> All timezone identifiers are written in plain US-ASCII. Lowercase ASCII >> characters are in 0x61-0x7A range, uppercase characters are in >> 0x41-0x5A. >> Maybe you can add 0x20 to all 0x41-0x5A byte values and use strcmp() >> instead of strcasecmp(). > > Looks way overcomplicated comparing to the Ilia's solution. PHP needs locale insensitive strcasecmp() or your developers will continue hitting string comparison issues in Turkish and Azerbaijani. Ilia patched it in timezone parsing code. Some day other strcasecmp will pop in other place. Switching locale everytime you want to compare strings is a hack and not a bug fix. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 01/25/2007 04:02 PM, Tomas Kuliavas wrote: Test script: --- Ok, this is now fixed. Is it that difficult to replace strcasecmp with locale independent case insensitive comparison function? We're open for patches. Feel free to send one. I am PHP developer and don't code in C. In PHP script locale insensitive strtolower/strtoupper can be done with one preg_replace call. Making PCRE a requirement for ext/date is not an option. All timezone identifiers are written in plain US-ASCII. Lowercase ASCII characters are in 0x61-0x7A range, uppercase characters are in 0x41-0x5A. Maybe you can add 0x20 to all 0x41-0x5A byte values and use strcmp() instead of strcasecmp(). Looks way overcomplicated comparing to the Ilia's solution. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
>>> The 2nd release candidate for PHP 5.2.1 is now available for download. >>> The tarballs can be found here: >>> >>> http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2 >>> (d3889eda8c3471ce7cf2adb35a4de736) >>> http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz >>> (c5b3e5540d1951d4c4b976b8a39c09ab) >>> >>> and the Win32 binaries will be available in short order. >>> >>> Since the last release, there are over 20 different bug fixes resolving >>> some annoying engine issues such as the tempval leak inside foreach(). >>> We do not anticipate any regressions to be introduced by this RC, but I >>> would still like to ask everyone to take a few minutes and test it >>> against their code base. If you come across any issues please report >>> them at http://bugs.php.net/. >>> >>> Depending on the stability of this release it may either be followed by >>> a final release or another RC, therefor your feedback is critical to >>> determining whether or not the code is stable enough to warrant the >>> 5.2.1 final. >> >> Bugfix for #39993 introduced LC_CTYPE variable corruption. > > Please provide more details on this. > >> Comments in bug report stated that patch is not correct, yet patch was >> commited to cvs. >From http://bugs.php.net/bug.php?id=39993 Test script: --- http://cvs.php.net/viewvc.cgi/php-src/ext/date/lib/parse_tz.c?view=log OS - Linux Debian Etch. glibc 2.3.6. Tested PHP versions: * php 5.2.0-8 debian - timezone database corruption error * php5.2-200701011130 - timezone database corruption error * php5.2-200701241930 - LC_CTYPE environment variable is modified after date_default_timezone_set/get calls. If you set LC_CTYPE to C, you might break gettext translations that don't set codeset with bind_textdomain_codeset(). >> Is it that difficult to replace strcasecmp with locale independent case >> insensitive comparison function? > > We're open for patches. Feel free to send one. I am PHP developer and don't code in C. In PHP script locale insensitive strtolower/strtoupper can be done with one preg_replace call. All timezone identifiers are written in plain US-ASCII. Lowercase ASCII characters are in 0x61-0x7A range, uppercase characters are in 0x41-0x5A. Maybe you can add 0x20 to all 0x41-0x5A byte values and use strcmp() instead of strcasecmp(). -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.2.1RC3 Released
On 01/25/2007 02:36 PM, Tomas Kuliavas wrote: The 2nd release candidate for PHP 5.2.1 is now available for download. The tarballs can be found here: http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2 (d3889eda8c3471ce7cf2adb35a4de736) http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz (c5b3e5540d1951d4c4b976b8a39c09ab) and the Win32 binaries will be available in short order. Since the last release, there are over 20 different bug fixes resolving some annoying engine issues such as the tempval leak inside foreach(). We do not anticipate any regressions to be introduced by this RC, but I would still like to ask everyone to take a few minutes and test it against their code base. If you come across any issues please report them at http://bugs.php.net/. Depending on the stability of this release it may either be followed by a final release or another RC, therefor your feedback is critical to determining whether or not the code is stable enough to warrant the 5.2.1 final. Bugfix for #39993 introduced LC_CTYPE variable corruption. Please provide more details on this. Comments in bug report stated that patch is not correct, yet patch was commited to cvs. Is it that difficult to replace strcasecmp with locale independent case insensitive comparison function? We're open for patches. Feel free to send one. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.2.1RC3 Released
> The 2nd release candidate for PHP 5.2.1 is now available for download. > The tarballs can be found here: > > http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2 > (d3889eda8c3471ce7cf2adb35a4de736) > http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz > (c5b3e5540d1951d4c4b976b8a39c09ab) > > and the Win32 binaries will be available in short order. > > Since the last release, there are over 20 different bug fixes resolving > some annoying engine issues such as the tempval leak inside foreach(). > We do not anticipate any regressions to be introduced by this RC, but I > would still like to ask everyone to take a few minutes and test it > against their code base. If you come across any issues please report > them at http://bugs.php.net/. > > Depending on the stability of this release it may either be followed by > a final release or another RC, therefor your feedback is critical to > determining whether or not the code is stable enough to warrant the > 5.2.1 final. Bugfix for #39993 introduced LC_CTYPE variable corruption. Comments in bug report stated that patch is not correct, yet patch was commited to cvs. Is it that difficult to replace strcasecmp with locale independent case insensitive comparison function? -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
