#48766 [NEW]: gpf on imap on when using OP_PROTOTYPE option (Reopened)
From: d_kelsey at uk dot ibm dot com Operating system: linux PHP version: 5.2CVS-2009-07-02 (snap) PHP Bug Type: IMAP related Bug description: gpf on imap on when using OP_PROTOTYPE option (Reopened) Description: I was not able to re-open bug 48400 so have created a new bug with the extra information. I asked the question on the c-client mailing list using the example code provided in bug http://bugs.php.net/bug.php?id=48400 and the response implies that php code is at fault here - This is not a bug. Rather, you have misunderstood some important points. There are three issues with your sample program. [1] You SHOULD include c-client.h, and not mail.h directly. mail.h has most, but not all, of the consumer API definitions and prototypes. [2] You MUST (repeat, MUST!!) include linkage.c at the start of your main() function instead of calling mail_link() directly. [3] A prototype stream is not something that can be given to mail_close_full(). Without knowing why you are opening a prototype stream, it appears to me that you do not understand what a prototype stream is and how/why it is used; especially since this is an IMAP prototype stream, something which is almost completely useless except for internal c-client purposes. A prototype stream is not a stream. The closest analog to a prototype stream would be a factory object or class definition. Internally, a prototype stream is simply a pointer to a static area of constant memory that has the dtb for that driver. Prototype streams have VERY limited use to API consumers. The primary consumer use is that of a local filesystem format prototype stream as an argument to mail_create() to force the created mailbox to be in that format. However, that use is deprecated in favor of the #driver.???/ prefix; e.g., mail_create (NIL,"#driver.mix/newbox"); is the preferred and more modern way of doing mail_create (mail_open (NIL,existingmixmailbox,OP_PROTOTYPE),"newbox"); The prototype stream method is the way to create a new local filesystem mailbox of the same format as an existing local filesystem mailbox, as opposed to a specified format via the #driver.???/ syntax . This is therefore the 99% reason why any API consumer would use a prototype stream. Your use may be in the remaining 1% (it would have to be, given that it's an IMAP prototype stream), but I suspect that it's really a case of your not understanding what you are doing. Getting back to the subject at hand; since it is a factory object (or class definition), it is inappropriate to call non-factory methods on it. For most API consumers, other than mail_create() with a local filesystem driver prototype, the remaining uses are power tools for master sorcerers. mail_close() and mail_close_full() are completely inappropriate methods to use with a prototype stream, even for a master sorcerer. A prototype stream is not a stream, and is not something that can be closed. When you are finished with a prototype stream, you just drop the pointer. -- Mark -- - The simpliest solution would be to remove the OP_PROTOTYPE option but the response may indicate a concern in general in the way php uses the c-client apis. -- Edit bug report at http://bugs.php.net/?id=48766&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48766&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48766&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48766&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48766&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48766&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48766&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48766&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48766&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48766&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48766&r=support Expected behavior: http://bugs.php.net/fix.php?id=48766&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48766&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48766&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48766&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48766&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48766&r=dst IIS Stability:
#43314 [Com]: iconv_mime_encode(), broken Q scheme
ID: 43314
Comment by: d_kelsey at uk dot ibm dot com
Reported By: wiela at centras dot lt
Status: Open
Bug Type: ICONV related
Operating System: Windows XP HE
PHP Version: 5.2.5
New Comment:
I encountered a similar problem with another utf-8 string, and although
this may not be the best way to fix it, this change provides a
workaround.
in iconv.c (line 1281 in php5.2.5) the line
out_size -= ((nbytes_required - (char_cnt - 2)) + 1) / (3 - 1);
should be changed to
out_size -= ((nbytes_required - (char_cnt - 2)) + 1) / 3;
It looks like the code attempts to determine how many characters would
fit into output buffer when converted (given that it has gone over the
limit), but it assumes that on average each character uses 2 bytes (ie
an even mixture of encoded and printable characters). A lot of strings
will be greater than this and out_size will be set to a very large
positive number (as it subtracts a larger number from out_size and being
unsigned will result in a large positive number).
The workaround is to take the worst case scenario and assume all
characters generated 3 bytes (ie all encoded).
Previous Comments:
[2007-11-16 16:23:17] wiela at centras dot lt
Description:
iconv_mime_encode(),'Q' encoding scheme isn't reliable and
sometimes (for particular character and/or string length combination?)
returns: "Notice: iconv_mime_encode(): Unknown error (7) in ..."
*without any result*.
This also applies to earlier php versions (tested with php 5.2.1).
Reproduce code:
---
$preferences = array(
"input-charset" => "UTF-8",
"output-charset" => "UTF-8",
"line-length" => 76,
"line-break-chars" => "\n",
"scheme" => "Q"
);
// $str1 results error, it's utf-8 string, its base64_encode() is:
//'xIXEjcSZxJfEr8WhxbPFviDEr8SZxI3FocWzxJnEr8SFIMSNxJnFs8SFxaHFs8Wr'
$str1 = "ąčęėįų
įęčųęįą
čęųąųū";
// $str2 doesn't result error, although it's only one character
// shorter. It's utf-8 string, its base64_encode() is:
//'xIXEjcSZxJfEr8WhxbPFviDEr8SZxI3FocWzxJnEr8SFIMSNxJnFs8SFxaHFsw=='
$str2 = "ąčęėįų
įęčųęįą
čęųąų";
echo iconv_mime_encode("Subject", $str1, $preferences);
echo iconv_mime_encode("Subject", $str2, $preferences);
Expected result:
Well, at least any (*some*) result is expected, without any
errors and warnings.
For $str1 is expected:
Subject: =?UTF-8?Q?=C4=85=C4=8D=C4=99=C4=97=C4=AF=C5=A1=C5=B3?=
=?UTF-8?Q?=C5=BE=20=C4=AF=C4=99=C4=8D=C5=A1=C5=B3=C4=99=C4=AF?=
=?UTF-8?Q?=C4=85=20=C4=8D=C4=99=C5=B3=C4=85=C5=A1=C5=B3=C5=AB?=
For $str2 is expected:
Subject: =?UTF-8?Q?=C4=85=C4=8D=C4=99=C4=97=C4=AF=C5=A1=C5=B3?=
=?UTF-8?Q?=C5=BE=20=C4=AF=C4=99=C4=8D=C5=A1=C5=B3=C4=99=C4=AF?=
=?UTF-8?Q?=C4=85=20=C4=8D=C4=99=C5=B3=C4=85=C5=A1=C5=B3?=
Actual result:
--
For $str1:
FALSE with "Notice: iconv_mime_encode(): Unknown error (7) in ..."
For $str2:
Subject: =?UTF-8?Q?=C4=85=C4=8D=C4=99=C4=97=C4=AF=C5=A1=C5=B3?=
=?UTF-8?Q?=C5=BE=20=C4=AF=C4=99=C4=8D=C5=A1=C5=B3=C4=99=C4=AF?=
=?UTF-8?Q?=C4=85=20=C4=8D=C4=99=C5=B3=C4=85=C5=A1=C5=B3?=
--
Edit this bug report at http://bugs.php.net/?id=43314&edit=1
#45923 [NEW]: mb_stripos & mb_strripos offset not handled correctly
From: d_kelsey at uk dot ibm dot com
Operating system: Windows XP
PHP version: 5.2.6
PHP Bug Type: mbstring related
Bug description: mb_stripos & mb_strripos offset not handled correctly
Description:
The offset checking in mb_stripos and mb_strripos doesn't match the case
sensitive equivalents with regard to character counts rather than byte
counts. More importantly entering a negative offset in mb_strripos results
in a "Offset not contained in string." message which was not expected.
Suggested code changes.
mb_stripos function add the check:
if (offset < 0 || (unsigned long)offset > (unsigned
long)mbfl_strlen(&old_haystack)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Offset not
contained in
string.");
RETURN_FALSE;
}
mb_strripos function add the check:
if ((offset > 0 && offset > mbfl_strlen(&old_haystack)) ||
(offset < 0 && -offset > mbfl_strlen(&old_haystack))) {
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Offset is greater
than the
length of haystack string");
RETURN_FALSE;
}
php_mb_stripos function remove the check:
if (offset < 0 || (unsigned long)offset > haystack.len) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Offset not
contained in
string.");
break;
}
Reproduce code:
---
Expected result:
int(5)
Actual result:
--
Warning: mb_strripos(): Offset not contained in string. in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
--
Edit bug report at http://bugs.php.net/?id=45923&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45923&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45923&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45923&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45923&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45923&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45923&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45923&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45923&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45923&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45923&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45923&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45923&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45923&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45923&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45923&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45923&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45923&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45923&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45923&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45923&r=mysqlcfg
#45924 [NEW]: 2 similar warning messages on mb_strpos and mb_stripos
From: d_kelsey at uk dot ibm dot com
Operating system: Windows XP
PHP version: 5.2.6
PHP Bug Type: mbstring related
Bug description: 2 similar warning messages on mb_strpos and mb_stripos
Description:
2 warnings are generated when passed an unknown encoding, but one would
suffice.The case sensitive versions only produce one.
Suggested code change in php_mb_stripos function
Move the following code to just below the "do {" line
haystack.no_encoding = needle.no_encoding =
mbfl_name2no_encoding(from_encoding);
if (haystack.no_encoding == mbfl_no_encoding_invalid) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unknown
encoding \"%s\"",
from_encoding);
break;
}
Reproduce code:
---
Expected result:
Warning: mb_strripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
Warning: mb_stripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
bool(false)
Actual result:
--
Warning: mb_strripos(): Illegal character encoding specified in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
Warning: mb_strripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
Warning: mb_stripos(): Illegal character encoding specified in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
Warning: mb_stripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
bool(false)
--
Edit bug report at http://bugs.php.net/?id=45924&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45924&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45924&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45924&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45924&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45924&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45924&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45924&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45924&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45924&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45924&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45924&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45924&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45924&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45924&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45924&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45924&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45924&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45924&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45924&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45924&r=mysqlcfg
#45924 [Opn->Bgs]: 2 similar warning messages on mb_strpos and mb_stripos
ID: 45924
User updated by: d_kelsey at uk dot ibm dot com
Reported By: d_kelsey at uk dot ibm dot com
-Status: Open
+Status: Bogus
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.6
New Comment:
my 5.2.6 install was pointing to 525 mbstring library. Problem has been
fixed.
Previous Comments:
[2008-08-26 16:20:05] d_kelsey at uk dot ibm dot com
Description:
2 warnings are generated when passed an unknown encoding, but one would
suffice.The case sensitive versions only produce one.
Suggested code change in php_mb_stripos function
Move the following code to just below the "do {" line
haystack.no_encoding = needle.no_encoding =
mbfl_name2no_encoding(from_encoding);
if (haystack.no_encoding == mbfl_no_encoding_invalid) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unknown
encoding
\"%s\"", from_encoding);
break;
}
Reproduce code:
---
Expected result:
Warning: mb_strripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
Warning: mb_stripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
bool(false)
Actual result:
--
Warning: mb_strripos(): Illegal character encoding specified in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
Warning: mb_strripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
Warning: mb_stripos(): Illegal character encoding specified in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
Warning: mb_stripos(): Unknown encoding "invalid" in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 3
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=45924&edit=1
#46010 [NEW]: warnings incorrectly generated for iv in ecb mode
From: d_kelsey at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2.6 PHP Bug Type: mcrypt related Bug description: warnings incorrectly generated for iv in ecb mode Description: With the functions mcrypt_encrypt, mcrypt_decrypt with MCRYPT_MODE_ECB and mcrypt_ecb, by not providing an initial vector or providing one that isn't at the correct block size results in a warning being generated. ECB mode never uses the initial vector, so a warning is irrelevant. Reproduce code: --- Expected result: string(16) "372eeb4a524b8d31" string(16) "372eeb4a524b8d31" string(16) "372eeb4a524b8d31" Actual result: -- Warning: mcrypt_encrypt(): Attempt to use an empty IV, which is NOT recommend in C:\udata-eclipse\p8\a.phpcode\mcrypt_ecb.php on line 2 string(16) "372eeb4a524b8d31" Warning: mcrypt_encrypt(): The IV parameter must be as long as the blocksize in C:\udata-eclipse\p8\a.phpcode\mcrypt_ecb.php on line 3 string(16) "372eeb4a524b8d31" string(16) "372eeb4a524b8d31" -- Edit bug report at http://bugs.php.net/?id=46010&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46010&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46010&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46010&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46010&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46010&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46010&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46010&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46010&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46010&r=support Expected behavior:http://bugs.php.net/fix.php?id=46010&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46010&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46010&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46010&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46010&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46010&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46010&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46010&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46010&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46010&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46010&r=mysqlcfg
#45923 [NoF->Opn]: mb_st[r]ripos() offset not handled correctly
ID: 45923
User updated by: d_kelsey at uk dot ibm dot com
Reported By: d_kelsey at uk dot ibm dot com
-Status: No Feedback
+Status: Open
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.6
New Comment:
as of php 5.2.8 this bug is still present
Previous Comments:
[2008-12-05 13:37:43] a...@php.net
I re-tested, this is still happening on the latest 5.2 snap.
[2008-11-03 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-10-26 19:28:18] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-08-26 16:07:42] d_kelsey at uk dot ibm dot com
Description:
The offset checking in mb_stripos and mb_strripos doesn't match the
case sensitive equivalents with regard to character counts rather than
byte counts. More importantly entering a negative offset in mb_strripos
results in a "Offset not contained in string." message which was not
expected.
Suggested code changes.
mb_stripos function add the check:
if (offset < 0 || (unsigned long)offset > (unsigned
long)mbfl_strlen(&old_haystack)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Offset not
contained in
string.");
RETURN_FALSE;
}
mb_strripos function add the check:
if ((offset > 0 && offset > mbfl_strlen(&old_haystack)) ||
(offset < 0 && -offset > mbfl_strlen(&old_haystack))) {
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Offset is greater
than
the length of haystack string");
RETURN_FALSE;
}
php_mb_stripos function remove the check:
if (offset < 0 || (unsigned long)offset > haystack.len) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Offset not
contained in
string.");
break;
}
Reproduce code:
---
Expected result:
int(5)
Actual result:
--
Warning: mb_strripos(): Offset not contained in string. in
C:\udata-eclipse\p8\a.phpcode\testmb.php on line 2
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=45923&edit=1
#44683 [NoF->Opn]: popen with modes such as "e" or "er" cause php.exe to crash
ID: 44683 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com -Status: No Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2CVS-2008-04-18 Assigned To: pajoye New Comment: This is still a problem in php528. The crash looks like it is due to a bug in the Microsoft C runtime library when calling _fdopen and the type being passed to it is "e". I think popen_ex in tsrm_win32.c should check that the first byte is either "w" or "r" and if not raise a php warning "invalid argument". Then it should check if the 2nd byte is present and if so it should only allow "b" or "t" anything else should also raise a php warning "invalid argument". This should then bring php.net on windows in line with what happens on php.net for linux. Previous Comments: [2008-11-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-04 19:19:08] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can't reproduce it locally, can you try again with the new snaps please? ---------------------------- [2008-04-18 12:51:46] d_kelsey at uk dot ibm dot com fails on latest snapshot. Backtrace is > ntdll.dll!7c9010f3() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcrt.dll!77c3b974() msvcrt.dll!77c3eb23() msvcrt.dll!77c3eb13() msvcrt.dll!77c2e556() php5ts.dll!popen_ex(const char * command=0x0122c9c0, const char * type=0x0122db18, const char * cwd=0x00301cc0, char * env=0x) Line 239C php5ts.dll!virtual_popen(const char * command=0x0122c9c0, const char * type=0x0122db18, void * * * tsrm_ls=0x00301c80) Line 1172 + 0x24 bytes C php5ts.dll!zif_popen(int ht=19015924, _zval_struct * return_value=0x0122c9f0, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00301c80) Line 986 + 0x10 bytes C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x00c0fbd0, void * * * tsrm_ls=0x00301c80) Line 200 + 0x3d bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x00301c80) Line 1679 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0008, void * * * tsrm_ls=0x00301c80) Line 92 + 0xc bytesC php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x00c0fec8, void * * * tsrm_ls=0x00301c80) Line 2005 + 0x12 bytes C php.exe!main(int argc=2, char * * argv=0x00301cf0) Line 1141 C php.exe!_mainCRTStartup() + 0xe3 bytes kernel32.dll!7c816fd7() [2008-04-12 01:19:32] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi And if it stil crashes, provide a backtrace. ------------------------ [2008-04-10 11:58:45] d_kelsey at uk dot ibm dot com opps, looks like modes supplemented with b should also work on linux. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44683 -- Edit this bug report at http://bugs.php.net/?id=44683&edit=1
#44683 [Opn]: popen with modes such as "e" or "er" cause php.exe to crash
ID: 44683 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP -PHP Version: 5.2CVS-2008-04-18 +PHP Version: 5.2.8 Assigned To: pajoye New Comment: corrected the version field Previous Comments: [2009-01-19 17:51:32] d_kelsey at uk dot ibm dot com This is still a problem in php528. The crash looks like it is due to a bug in the Microsoft C runtime library when calling _fdopen and the type being passed to it is "e". I think popen_ex in tsrm_win32.c should check that the first byte is either "w" or "r" and if not raise a php warning "invalid argument". Then it should check if the 2nd byte is present and if so it should only allow "b" or "t" anything else should also raise a php warning "invalid argument". This should then bring php.net on windows in line with what happens on php.net for linux. [2008-11-12 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-11-04 19:19:08] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can't reproduce it locally, can you try again with the new snaps please? ---------------------------- [2008-04-18 12:51:46] d_kelsey at uk dot ibm dot com fails on latest snapshot. Backtrace is > ntdll.dll!7c9010f3() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcrt.dll!77c3b974() msvcrt.dll!77c3eb23() msvcrt.dll!77c3eb13() msvcrt.dll!77c2e556() php5ts.dll!popen_ex(const char * command=0x0122c9c0, const char * type=0x0122db18, const char * cwd=0x00301cc0, char * env=0x) Line 239C php5ts.dll!virtual_popen(const char * command=0x0122c9c0, const char * type=0x0122db18, void * * * tsrm_ls=0x00301c80) Line 1172 + 0x24 bytes C php5ts.dll!zif_popen(int ht=19015924, _zval_struct * return_value=0x0122c9f0, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00301c80) Line 986 + 0x10 bytes C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x00c0fbd0, void * * * tsrm_ls=0x00301c80) Line 200 + 0x3d bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x00301c80) Line 1679 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0008, void * * * tsrm_ls=0x00301c80) Line 92 + 0xc bytesC php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x00c0fec8, void * * * tsrm_ls=0x00301c80) Line 2005 + 0x12 bytes C php.exe!main(int argc=2, char * * argv=0x00301cf0) Line 1141 C php.exe!_mainCRTStartup() + 0xe3 bytes kernel32.dll!7c816fd7() [2008-04-12 01:19:32] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi And if it stil crashes, provide a backtrace. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44683 -- Edit this bug report at http://bugs.php.net/?id=44683&edit=1
#47152 [NEW]: gzseek/fseek using SEEK_END produces strange results
From: d_kelsey at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2.8 PHP Bug Type: Zlib Related Bug description: gzseek/fseek using SEEK_END produces strange results Description: I have opened a .gz file using gzopen for reading. I can pass SEEK_END with offset of 0 (which would seek to the end of the file) using either fseek or gzseek as a whence. This returns -1 (a failure), but a subsequent gztell/ftell returns false, but I can still read the stream from the position it was last in. The issue is 1. is a whence of SEEK_END supported for a zlib stream ? If it is then SEEK_END is very broken as it doesn't move it to the end of the stream. 2. if not supported, I should get a warning saying invalid parameter. Also a subsequent call to gztell/ftell returns false.a further read and gztell/ftell returns an incorrect value I couldn't find any information to say it was not a valid value so assumed that it was valid. Reproduce code: --- Expected result: If SEEK_END is not valid: string(10) "When you'r" move to the end gzseek= Warning: gzseek() SEEK_END not supported tell=int(10) eof=bool(false) string(10) "e taught t" tell=int(20) if SEEK_END is valid: string(10) "When you'r" move to the end gzseek=int(0) tell=int(176) eof=bool(true) string(0) "" tell=int(176) Actual result: -- string(10) "When you'r" move to the end gzseek=int(-1) tell=bool(false) eof=bool(false) string(10) "e taught t" tell=int(9) -- Edit bug report at http://bugs.php.net/?id=47152&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47152&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47152&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47152&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47152&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47152&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47152&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47152&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47152&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47152&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47152&r=support Expected behavior: http://bugs.php.net/fix.php?id=47152&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47152&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47152&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47152&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47152&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47152&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47152&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47152&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47152&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47152&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47152&r=mysqlcfg
#47152 [Com]: gzseek/fseek using SEEK_END produces strange results
ID: 47152 Comment by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Zlib Related Operating System: Windows XP PHP Version: 5.2.8 New Comment: There is also a problem using SEEK_END when opening a file for write mode. for example results in: bool(false) int(15) first sentence.second sentence. So the gztell results of bool(false)and then int(15) are both incorrect. Yet the file did get written correctly. Previous Comments: [2009-01-19 18:31:59] d_kelsey at uk dot ibm dot com Description: I have opened a .gz file using gzopen for reading. I can pass SEEK_END with offset of 0 (which would seek to the end of the file) using either fseek or gzseek as a whence. This returns -1 (a failure), but a subsequent gztell/ftell returns false, but I can still read the stream from the position it was last in. The issue is 1. is a whence of SEEK_END supported for a zlib stream ? If it is then SEEK_END is very broken as it doesn't move it to the end of the stream. 2. if not supported, I should get a warning saying invalid parameter. Also a subsequent call to gztell/ftell returns false.a further read and gztell/ftell returns an incorrect value I couldn't find any information to say it was not a valid value so assumed that it was valid. Reproduce code: --- Expected result: If SEEK_END is not valid: string(10) "When you'r" move to the end gzseek= Warning: gzseek() SEEK_END not supported tell=int(10) eof=bool(false) string(10) "e taught t" tell=int(20) if SEEK_END is valid: string(10) "When you'r" move to the end gzseek=int(0) tell=int(176) eof=bool(true) string(0) "" tell=int(176) Actual result: -- string(10) "When you'r" move to the end gzseek=int(-1) tell=bool(false) eof=bool(false) string(10) "e taught t" tell=int(9) -- Edit this bug report at http://bugs.php.net/?id=47152&edit=1
#47152 [Com]: gzseek/fseek using SEEK_END produces strange results
ID: 47152 Comment by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Zlib Related Operating System: Windows XP PHP Version: 5.2.8 New Comment: I would expect the gzseek to fail for SEEK_END on a write as this doesn't make any sense. The file pointer should not move which is the case but it seems that the tell value has been corrupted. Previous Comments: [2009-01-20 13:35:23] d_kelsey at uk dot ibm dot com There is also a problem using SEEK_END when opening a file for write mode. for example results in: bool(false) int(15) first sentence.second sentence. So the gztell results of bool(false)and then int(15) are both incorrect. Yet the file did get written correctly. [2009-01-19 18:31:59] d_kelsey at uk dot ibm dot com Description: I have opened a .gz file using gzopen for reading. I can pass SEEK_END with offset of 0 (which would seek to the end of the file) using either fseek or gzseek as a whence. This returns -1 (a failure), but a subsequent gztell/ftell returns false, but I can still read the stream from the position it was last in. The issue is 1. is a whence of SEEK_END supported for a zlib stream ? If it is then SEEK_END is very broken as it doesn't move it to the end of the stream. 2. if not supported, I should get a warning saying invalid parameter. Also a subsequent call to gztell/ftell returns false.a further read and gztell/ftell returns an incorrect value I couldn't find any information to say it was not a valid value so assumed that it was valid. Reproduce code: --- Expected result: If SEEK_END is not valid: string(10) "When you'r" move to the end gzseek= Warning: gzseek() SEEK_END not supported tell=int(10) eof=bool(false) string(10) "e taught t" tell=int(20) if SEEK_END is valid: string(10) "When you'r" move to the end gzseek=int(0) tell=int(176) eof=bool(true) string(0) "" tell=int(176) Actual result: -- string(10) "When you'r" move to the end gzseek=int(-1) tell=bool(false) eof=bool(false) string(10) "e taught t" tell=int(9) -- Edit this bug report at http://bugs.php.net/?id=47152&edit=1
#47171 [NEW]: Incorrect tell values when trying to seek beyond file range
From: d_kelsey at uk dot ibm dot com Operating system: Windows PHP version: 5.2.8 PHP Bug Type: Zlib Related Bug description: Incorrect tell values when trying to seek beyond file range Description: When attempting to seek a zlib stream outside the range of the file eg -50 or 2000 (and the uncompressed length is < 2000) in either read or write mode, after the seek operation a gztell call returns false. In most cases the file pointer doesn't move so I can perform further reads or writes but the tell value returns now an invalid value. If a attempt to seek forward in read mode beyond the end of the uncompressed stream it looks like the file pointer remains at the end of the stream as a subsequent read returns nothing. In all cases I would expect - seek & gzseek to return -1 - the file pointer to remain where it was - the tell to return the same value as before the seek In other words the operation fails and nothing changes. Reproduce code: --- Expected result: move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=int(40) string(10) "iny flying" tell=int(50) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=int(0) string(10) "When you'r" tell=int(10) Actual result: -- move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=bool(false) string(0) "" tell=bool(false) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=bool(false) string(10) "When you'r" tell=int(9) -- Edit bug report at http://bugs.php.net/?id=47171&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47171&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47171&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47171&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47171&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47171&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47171&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47171&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47171&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47171&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47171&r=support Expected behavior: http://bugs.php.net/fix.php?id=47171&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47171&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47171&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47171&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47171&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47171&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47171&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47171&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47171&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47171&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47171&r=mysqlcfg
#47171 [Com]: Incorrect tell values when trying to seek beyond file range
ID: 47171 Comment by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Zlib Related Operating System: Windows PHP Version: 5.2.8 New Comment: The provided test only covers the read scenario, but similar issues result when opening a zlib stream for write as well. Previous Comments: [2009-01-20 17:24:00] d_kelsey at uk dot ibm dot com Description: When attempting to seek a zlib stream outside the range of the file eg -50 or 2000 (and the uncompressed length is < 2000) in either read or write mode, after the seek operation a gztell call returns false. In most cases the file pointer doesn't move so I can perform further reads or writes but the tell value returns now an invalid value. If a attempt to seek forward in read mode beyond the end of the uncompressed stream it looks like the file pointer remains at the end of the stream as a subsequent read returns nothing. In all cases I would expect - seek & gzseek to return -1 - the file pointer to remain where it was - the tell to return the same value as before the seek In other words the operation fails and nothing changes. Reproduce code: --- Expected result: move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=int(40) string(10) "iny flying" tell=int(50) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=int(0) string(10) "When you'r" tell=int(10) Actual result: -- move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=bool(false) string(0) "" tell=bool(false) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=bool(false) string(10) "When you'r" tell=int(9) -- Edit this bug report at http://bugs.php.net/?id=47171&edit=1
#47171 [Fbk->Opn]: Incorrect tell values when trying to seek beyond file range
ID: 47171 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com -Status: Feedback +Status: Open Bug Type: Zlib Related Operating System: Windows -PHP Version: 5.2.8 +PHP Version: 5.2.9 snap jan21 New Comment: The problem still exists in the latest windows snapshot for php 5.2 Previous Comments: [2009-01-20 19:06:19] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-01-20 17:25:01] d_kelsey at uk dot ibm dot com The provided test only covers the read scenario, but similar issues result when opening a zlib stream for write as well. [2009-01-20 17:24:00] d_kelsey at uk dot ibm dot com Description: When attempting to seek a zlib stream outside the range of the file eg -50 or 2000 (and the uncompressed length is < 2000) in either read or write mode, after the seek operation a gztell call returns false. In most cases the file pointer doesn't move so I can perform further reads or writes but the tell value returns now an invalid value. If a attempt to seek forward in read mode beyond the end of the uncompressed stream it looks like the file pointer remains at the end of the stream as a subsequent read returns nothing. In all cases I would expect - seek & gzseek to return -1 - the file pointer to remain where it was - the tell to return the same value as before the seek In other words the operation fails and nothing changes. Reproduce code: --- Expected result: move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=int(40) string(10) "iny flying" tell=int(50) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=int(0) string(10) "When you'r" tell=int(10) Actual result: -- move to the 40th byte seek=int(0) tell=40 try to move beyond the file seek=int(-1) tell=bool(false) string(0) "" tell=bool(false) rewinding and try to move to before the start tell=0 gzseek=int(-1) tell=bool(false) string(10) "When you'r" tell=int(9) -- Edit this bug report at http://bugs.php.net/?id=47171&edit=1
#47422 [NEW]: modulus operator returns incorrect results on 64 bit linux
From: d_kelsey at uk dot ibm dot com
Operating system: Linux 64Bit
PHP version: 5.2CVS-2009-02-17 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: modulus operator returns incorrect results on 64 bit linux
Description:
on a 64bit system the following
var_dump(1%4294967295);
should return 1, but returns 0.
The problem is in the
ZEND_API int mod_function(...) in zend_operators.c
A call is made to abs which expects a 32bit int and returns a 32bit int,
but 4294967295 is > 32 bits in size so the abs call returns an incorrect
value.
A proposed fix is to change the line
"if (abs(op2->value.lval) == 1) {"
to
"if (op2->value.lval == 1 || op2->value.lval == -1) {"
--
Edit bug report at http://bugs.php.net/?id=47422&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47422&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47422&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47422&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47422&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47422&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47422&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47422&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47422&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47422&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47422&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47422&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47422&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47422&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47422&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47422&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47422&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47422&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47422&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47422&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47422&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47422&r=mysqlcfg
#47424 [NEW]: not operator does a c cast to long which is different to other ops
From: d_kelsey at uk dot ibm dot com
Operating system: Linux 64Bit
PHP version: 5.2CVS-2009-02-17 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: not operator does a c cast to long which is different to
other ops
Description:
In zend_operators.c the function ZEND_API int bitwise_not_function(..)
handles a double by doing a c cast to a long
"if (op1->type == IS_DOUBLE) {
op1->value.lval = (long) op1->value.dval;
op1->type = IS_LONG;
}"
but all other operators use the zendi_convert_to_long() macro
so not isn't consistent with the other operators.
this can result in an unexpected value as shown in the test case
Reproduce code:
---
Expected result:
int(-9223372036854775808)
int(-9223372036854775808)
Actual result:
--
int(9223372036854775807)
int(-9223372036854775808)
--
Edit bug report at http://bugs.php.net/?id=47424&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47424&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47424&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47424&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47424&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47424&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47424&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47424&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47424&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47424&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47424&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47424&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47424&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47424&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47424&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47424&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47424&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47424&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47424&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47424&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47424&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47424&r=mysqlcfg
#47886 [NEW]: file system time functions not backported from 5.3/6, eg touch
From: d_kelsey at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2.9 PHP Bug Type: Filesystem function related Bug description: file system time functions not backported from 5.3/6, eg touch Description: touch_basic-win32.phpt test fails once we entered DST. I see in 5.3/5 this area has been looked into because the microsoft C runtime functions appear to be sensitive to DST (by design!) I was wondering if this code was going to be backported to 5.2.x stream ? If not then maybe the expectf section for touch_basic-win32.phpt should be changed from mtime=1 atime=20470 to mtime=%r1|6400%r atime=%r20470|16870%r -- Edit bug report at http://bugs.php.net/?id=47886&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47886&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47886&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47886&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47886&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47886&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47886&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47886&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47886&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47886&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47886&r=support Expected behavior: http://bugs.php.net/fix.php?id=47886&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47886&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47886&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47886&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47886&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47886&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47886&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47886&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47886&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47886&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47886&r=mysqlcfg
#47886 [Opn]: file system time functions not backported from 5.3/6, eg touch
ID: 47886 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.2.9 New Comment: Its new to runtests. Anything inside the %r...%r section is treated as a regular expression. If you want I can commit an update to the 5.2.x test ? Previous Comments: [2009-04-03 12:51:38] paj...@php.net No, they will not be backported. Does the | operator works in 5.2 run-tests? I never used it :) [2009-04-03 12:07:30] d_kelsey at uk dot ibm dot com Description: touch_basic-win32.phpt test fails once we entered DST. I see in 5.3/5 this area has been looked into because the microsoft C runtime functions appear to be sensitive to DST (by design!) I was wondering if this code was going to be backported to 5.2.x stream ? If not then maybe the expectf section for touch_basic-win32.phpt should be changed from mtime=1 atime=20470 to mtime=%r1|6400%r atime=%r20470|16870%r -- Edit this bug report at http://bugs.php.net/?id=47886&edit=1
#47886 [Asn]: file system time functions not backported from 5.3/6, eg touch
ID: 47886 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Assigned Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.2.9 Assigned To: pajoye New Comment: new test has been committed to cvs for php 5.2 stream Previous Comments: [2009-04-03 13:06:34] paj...@php.net If it works in 5.2, yes please do :) Thanks! [2009-04-03 13:02:34] d_kelsey at uk dot ibm dot com Its new to runtests. Anything inside the %r...%r section is treated as a regular expression. If you want I can commit an update to the 5.2.x test ? [2009-04-03 12:51:38] paj...@php.net No, they will not be backported. Does the | operator works in 5.2 run-tests? I never used it :) [2009-04-03 12:07:30] d_kelsey at uk dot ibm dot com Description: touch_basic-win32.phpt test fails once we entered DST. I see in 5.3/5 this area has been looked into because the microsoft C runtime functions appear to be sensitive to DST (by design!) I was wondering if this code was going to be backported to 5.2.x stream ? If not then maybe the expectf section for touch_basic-win32.phpt should be changed from mtime=1 atime=20470 to mtime=%r1|6400%r atime=%r20470|16870%r -- Edit this bug report at http://bugs.php.net/?id=47886&edit=1
#44014 [Com]: mb_convert_encoding 'destroys' first character (UTF16->UTF8)
ID: 44014
Comment by: d_kelsey at uk dot ibm dot com
Reported By: michael202 at gmx dot de
Status: No Feedback
Bug Type: mbstring related
Operating System: Win XP
PHP Version: 5.2.5
Assigned To: hirokawa
New Comment:
My understanding of UTF-16 is that the BOM is a mandatory. For mbstring
I have found that if I input a UTF-16 string for conversion in
mb_convert_encoding for example to UTF-8, it treats the BOM as UTF-16
data and converts it.
MBString doesn't generate the BOM when converting to UTF-16, so as I
thought the BOM was mandatory, it isn't generating valid UTF-16 bytes.
I see that MBString uses UTF-16BE effectively when you specify UTF-16.
If mbstring doesn't support BOM then UTF-16 cannot be handled properly.
Should this at least be documented and recommend considering using
UTF-16BE as the encoding so that you are explicit in what is supportable
?
Previous Comments:
[2008-02-24 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-02-16 12:17:13] [EMAIL PROTECTED]
BOM of Unicode is not supported by encoding conversion function
in mbstring.
And big endian is default in UTF-16. Please specify 'UTF-16LE'
if you need to specify little endian format.
Try,
Mo
?>
or
Mo
?>
[2008-02-05 05:10:37] [EMAIL PROTECTED]
Assigned to the mbstring maintainer.
[2008-02-01 12:08:07] michael202 at gmx dot de
Description:
mb_convert_encoding 'destroys' first character when
converting from UTF16 to UTF8
(iconv works).
Reproduce code:
---
$utf16 = chr(0xFF).chr(0xFE).chr(0x4d).chr(0).chr(0x6f).chr(0); //'Mo'
$utf8 = mb_convert_encoding($utf16, 'UTF-8', 'UTF-16');
echo($utf8 . "\n"); // -> ´++´¢ìo
$utf8 = iconv('UTF-16', 'UTF-8', $utf16);
echo($utf8 . "\n"); // -> Mo
Expected result:
mb:(BOM8)Mo
iconv: Mo
(BOM8) is a placeholder
Actual result:
--
mb:(BOM8)´¢ìo (copied from cmd shell)
iconv: Mo
(BOM8) is a placeholder
--
Edit this bug report at http://bugs.php.net/?id=44014&edit=1
#44683 [NEW]: popen with modes such as "e" or "er" cause php.exe to crash
From: d_kelsey at uk dot ibm dot com Operating system: Windows XP PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: popen with modes such as "e" or "er" cause php.exe to crash Description: trying different modes on php.exe on windows. I tried "e" and "er". Both cause php to crash. a mode of "re" works. This is also different from linux where it seems that only "r" or "w" are valid modes. Anything else or more than 1 character result in a php warning of invalid argument. Reproduce code: --- Expected result: Expected output would be the same as linux. Warning: popen(echo hello,e): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 2 Warning: popen(echo hello,re): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 4 Warning: popen(echo hello,er): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 6 Actual result: -- Windows crashes on "e" and "er" but allows "re" -- Edit bug report at http://bugs.php.net/?id=44683&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44683&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44683&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44683&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44683&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44683&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44683&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44683&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44683&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44683&r=support Expected behavior:http://bugs.php.net/fix.php?id=44683&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44683&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44683&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44683&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44683&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44683&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44683&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44683&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44683&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44683&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44683&r=mysqlcfg
#44683 [Opn]: popen with modes such as "e" or "er" cause php.exe to crash
ID: 44683 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 New Comment: One thing I missed, on windows you should be able to specify b or t as a supplement to r and w, ie rb, rt, wb, wt, so modes of 2 characters should be allowed on windows. Previous Comments: [2008-04-10 11:43:38] d_kelsey at uk dot ibm dot com Description: trying different modes on php.exe on windows. I tried "e" and "er". Both cause php to crash. a mode of "re" works. This is also different from linux where it seems that only "r" or "w" are valid modes. Anything else or more than 1 character result in a php warning of invalid argument. Reproduce code: --- Expected result: Expected output would be the same as linux. Warning: popen(echo hello,e): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 2 Warning: popen(echo hello,re): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 4 Warning: popen(echo hello,er): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 6 Actual result: -- Windows crashes on "e" and "er" but allows "re" -- Edit this bug report at http://bugs.php.net/?id=44683&edit=1
#44683 [Opn]: popen with modes such as "e" or "er" cause php.exe to crash
ID: 44683 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 New Comment: opps, looks like modes supplemented with b should also work on linux. Previous Comments: [2008-04-10 11:51:18] d_kelsey at uk dot ibm dot com One thing I missed, on windows you should be able to specify b or t as a supplement to r and w, ie rb, rt, wb, wt, so modes of 2 characters should be allowed on windows. [2008-04-10 11:43:38] d_kelsey at uk dot ibm dot com Description: trying different modes on php.exe on windows. I tried "e" and "er". Both cause php to crash. a mode of "re" works. This is also different from linux where it seems that only "r" or "w" are valid modes. Anything else or more than 1 character result in a php warning of invalid argument. Reproduce code: --- Expected result: Expected output would be the same as linux. Warning: popen(echo hello,e): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 2 Warning: popen(echo hello,re): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 4 Warning: popen(echo hello,er): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 6 Actual result: -- Windows crashes on "e" and "er" but allows "re" -- Edit this bug report at http://bugs.php.net/?id=44683&edit=1
#44683 [Fbk->Opn]: popen with modes such as "e" or "er" cause php.exe to crash
ID: 44683 User updated by: d_kelsey at uk dot ibm dot com Reported By: d_kelsey at uk dot ibm dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.5 New Comment: fails on latest snapshot. Backtrace is > ntdll.dll!7c9010f3() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] msvcrt.dll!77c3b974() msvcrt.dll!77c3eb23() msvcrt.dll!77c3eb13() msvcrt.dll!77c2e556() php5ts.dll!popen_ex(const char * command=0x0122c9c0, const char * type=0x0122db18, const char * cwd=0x00301cc0, char * env=0x) Line 239C php5ts.dll!virtual_popen(const char * command=0x0122c9c0, const char * type=0x0122db18, void * * * tsrm_ls=0x00301c80) Line 1172 + 0x24 bytes C php5ts.dll!zif_popen(int ht=19015924, _zval_struct * return_value=0x0122c9f0, _zval_struct * * return_value_ptr=0x, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00301c80) Line 986 + 0x10 bytes C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data=0x00c0fbd0, void * * * tsrm_ls=0x00301c80) Line 200 + 0x3d bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data=0x, void * * * tsrm_ls=0x00301c80) Line 1679 + 0xe bytes C php5ts.dll!execute(_zend_op_array * op_array=0x0008, void * * * tsrm_ls=0x00301c80) Line 92 + 0xc bytesC php5ts.dll!php_execute_script(_zend_file_handle * primary_file=0x00c0fec8, void * * * tsrm_ls=0x00301c80) Line 2005 + 0x12 bytes C php.exe!main(int argc=2, char * * argv=0x00301cf0) Line 1141 C php.exe!_mainCRTStartup() + 0xe3 bytes kernel32.dll!7c816fd7() Previous Comments: [2008-04-12 01:19:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi And if it stil crashes, provide a backtrace. [2008-04-10 11:58:45] d_kelsey at uk dot ibm dot com opps, looks like modes supplemented with b should also work on linux. [2008-04-10 11:51:18] d_kelsey at uk dot ibm dot com One thing I missed, on windows you should be able to specify b or t as a supplement to r and w, ie rb, rt, wb, wt, so modes of 2 characters should be allowed on windows. [2008-04-10 11:43:38] d_kelsey at uk dot ibm dot com Description: trying different modes on php.exe on windows. I tried "e" and "er". Both cause php to crash. a mode of "re" works. This is also different from linux where it seems that only "r" or "w" are valid modes. Anything else or more than 1 character result in a php warning of invalid argument. Reproduce code: --- Expected result: Expected output would be the same as linux. Warning: popen(echo hello,e): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 2 Warning: popen(echo hello,re): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 4 Warning: popen(echo hello,er): Invalid argument in /data/workspace/phpcode/popen/badpopen.php on line 6 Actual result: -- Windows crashes on "e" and "er" but allows "re" -- Edit this bug report at http://bugs.php.net/?id=44683&edit=1
