#48276 [Opn-Asn]: date('Y') returns 0000

2009-05-28 Thread derick
 ID:   48276
 Updated by:   der...@php.net
 Reported By:  info at programmiernutte dot net
-Status:   Open
+Status:   Assigned
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
-Assigned To:  
+Assigned To:  derick
 New Comment:

Oh, I had forgotten about that PPC machine. I'll have a look.


Previous Comments:


[2009-05-28 03:56:41] scott...@php.net

We have a PPC test machine, Derick has access and I can set up other
accounts if needed.



[2009-05-28 00:45:05] ras...@php.net

So there is an endian issue somewhere.  How are you with gdb?  Could
you set a breakpoint on the function and work your way through it and
figure out where it goes south?



[2009-05-28 00:40:27] info at programmiernutte dot net

I just verified the issue unter Linux PPC, Debian Lenny PPC to be 
specific.



[2009-05-27 23:07:35] info at programmiernutte dot net

PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same 
results.



[2009-05-27 22:00:56] j at teamonetickets dot com

I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2.

$oDateTime = new DateTime();
print_r($oDateTime);

Result:
DateTime Object
(
[date] = 2009-05-27 14:57:33
[timezone_type] = 3
[timezone] = America/Phoenix
)

echo date('y');
Result:
09

echo date('Y');
Result:
2009



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/48276

-- 
Edit this bug report at http://bugs.php.net/?id=48276edit=1



#48276 [Asn]: date('Y') returns 0000

2009-05-28 Thread derick
 ID:   48276
 Updated by:   der...@php.net
 Reported By:  info at programmiernutte dot net
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: Mac OS X 10.4 PPC
 PHP Version:  5.3.0RC2
 Assigned To:  derick
 New Comment:

Seems like it's an issue in slprintf:

1017switch (format[i]) {
(gdb) 
1043timelib_sll year = PHP_LLABS(t-y);
(gdb) print year
$1 = 1230768000
(gdb) next
1044length = slprintf(buffer, 32, 
%s%04ld, t-y  0 ? - : ,
year); break;
(gdb) print year
$2 = 2009
(gdb) next
1124smart_str_appendl(string, buffer, length);
(gdb) print buffer
$3 =
\000\000\004\202\000\000\000\000\000\000\000\000I\\\a\200\000\000\000\000\000\000\0006\000\000\000\000
(gdb) next
1015for (i = 0; i  format_len; i++) {
(gdb) print string
$4 = (smart_str *) 0xffa1cde0
(gdb) print string
$5 = {c = 0x1071f060 \020q�X\020c\003�, len = 4, a = 78}



Previous Comments:


[2009-05-28 08:42:28] der...@php.net

Oh, I had forgotten about that PPC machine. I'll have a look.



[2009-05-28 03:56:41] scott...@php.net

We have a PPC test machine, Derick has access and I can set up other
accounts if needed.



[2009-05-28 00:45:05] ras...@php.net

So there is an endian issue somewhere.  How are you with gdb?  Could
you set a breakpoint on the function and work your way through it and
figure out where it goes south?



[2009-05-28 00:40:27] info at programmiernutte dot net

I just verified the issue unter Linux PPC, Debian Lenny PPC to be 
specific.



[2009-05-27 23:07:35] info at programmiernutte dot net

PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same 
results.



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/48276

-- 
Edit this bug report at http://bugs.php.net/?id=48276edit=1



#48412 [NEW]: session_start error send internal server error 500

2009-05-28 Thread plasmapermanent at msn dot com
From: plasmapermanent at msn dot com
Operating system: Windows XP SP3
PHP version:  5.2.9
PHP Bug Type: Session related
Bug description:  session_start error send internal server error 500

Description:

Just insert session_start() into code and got error.
I try to insert top of code. It still error.

Reproduce code:
---
Source Code

http://www.thaicybergames.com/webboard/index.php?topic=108158.0

MySQL

CREATE TABLE IF NOT EXISTS `p28officer` (
  `id` double unsigned NOT NULL,
  `user` char(20) COLLATE utf8_bin NOT NULL,
  `pass` char(20) COLLATE utf8_bin NOT NULL,
  `ldate` date DEFAULT NULL,
  `ltime` time DEFAULT NULL,
  `ip` varchar(15) COLLATE utf8_bin DEFAULT NULL,
  `lv` tinyint(4) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO `p28officer` (`id`, `user`, `pass`, `ldate`, `ltime`, `ip`,
`lv`) VALUES
(, 'xxx', 'xxx', '2009-05-28', '20:02:00', '127.0.0.1', 9);


Expected result:

I just send variable name and pass into this page.
It would be can use session and remember ssid variable as session to use
in other pages.

Actual result:
--
This error (HTTP 500 Internal Server Error) means that the website you are
visiting had a server problem which prevented the webpage from displaying.

If I remove that line. It work fine. But can't use session.
Juse enable that line this error was come.

-- 
Edit bug report at http://bugs.php.net/?id=48412edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48412r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48412r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48412r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48412r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48412r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48412r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48412r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48412r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48412r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48412r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48412r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48412r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48412r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48412r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48412r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48412r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48412r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48412r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48412r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48412r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48412r=mysqlcfg



#48412 [Opn-Fbk]: session_start error send internal server error 500

2009-05-28 Thread pajoye
 ID:   48412
 Updated by:   paj...@php.net
 Reported By:  plasmapermanent at msn dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Windows XP SP3
 PHP Version:  5.2.9
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2009-05-28 12:31:33] plasmapermanent at msn dot com

Description:

Just insert session_start() into code and got error.
I try to insert top of code. It still error.

Reproduce code:
---
Source Code

http://www.thaicybergames.com/webboard/index.php?topic=108158.0

MySQL

CREATE TABLE IF NOT EXISTS `p28officer` (
  `id` double unsigned NOT NULL,
  `user` char(20) COLLATE utf8_bin NOT NULL,
  `pass` char(20) COLLATE utf8_bin NOT NULL,
  `ldate` date DEFAULT NULL,
  `ltime` time DEFAULT NULL,
  `ip` varchar(15) COLLATE utf8_bin DEFAULT NULL,
  `lv` tinyint(4) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO `p28officer` (`id`, `user`, `pass`, `ldate`, `ltime`, `ip`,
`lv`) VALUES
(, 'xxx', 'xxx', '2009-05-28', '20:02:00', '127.0.0.1',
9);


Expected result:

I just send variable name and pass into this page.
It would be can use session and remember ssid variable as session to
use in other pages.

Actual result:
--
This error (HTTP 500 Internal Server Error) means that the website you
are visiting had a server problem which prevented the webpage from
displaying.

If I remove that line. It work fine. But can't use session.
Juse enable that line this error was come.





-- 
Edit this bug report at http://bugs.php.net/?id=48412edit=1



#48413 [NEW]: floating-point formats on 64 bit systems

2009-05-28 Thread vgabor at gmail dot com
From: vgabor at gmail dot com
Operating system: Linux x86_64
PHP version:  5.2.9
PHP Bug Type: Math related
Bug description:  floating-point formats on 64 bit systems

Description:

This in not quite bug, I think everybody know well the possible
float-integer conversation problems on the usual 32 bit systems, but the 64
bit systems give us some new ones.

On 64 bit, the float becomes actually less precise then the integer,
because the binary64 (double) floating point format what the PHP using is
up to 52+1 bits while the integer 63+1 bit. Most of the mathematical
functions are using and convert the numbers to float which historically
give better result on 32 bit system (52+1 bit versus 31+1 bit) but with 64
bit integer thats unfortunately not the case (52+1 bit instead of 63+1
bit)

Solving this problem I would recommend to introduce in the PHP the
binary128 (quad) floating point format from the latest floating-point
arithmetic standard (IEEE 754-2008, last year) which would give us 112+1
bits precision.

Reproduce code:
---
Just a quick example when it comes to numbers above 52+1 bit (the /
operator convert the result to float which leads to precision loss on 64
bit systems):

ini_set('precision', 99);
$X=4485476582;
   
$Y=4485476608;

echo ($X/10*10) === $X: .((int)($X/10*10) === $X ? 'true' :
'false').\n;
echo ($X/10*10) === $Y: .((int)($X/10*10) === $Y ? 'true' :
'false').\n\n;

echo ($X).\n;
echo ($X/10).\n;
echo ($X/10*10).\n;



-- 
Edit bug report at http://bugs.php.net/?id=48413edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48413r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48413r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48413r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48413r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48413r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48413r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48413r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48413r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48413r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48413r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48413r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48413r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48413r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48413r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48413r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48413r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48413r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48413r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48413r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48413r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48413r=mysqlcfg



#48378 [Ver]: exif_read_data() segfaults on certain corrupted .jpeg files

2009-05-28 Thread iliaa
 ID:   48378
 Updated by:   il...@php.net
 Reported By:  phpbug dot exif at sub dot noloop dot net
 Status:   Verified
 Bug Type: EXIF related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-27)
 New Comment:

On 64 bit linux I get no crash and no complaints from valgrind either.


Previous Comments:


[2009-05-27 19:05:13] j...@php.net

Verified with proper test script, this function never accepted array 
parameters:

?php
exif_read_data(
http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg;, 
FILE,COMPUTED,ANY_TAG
);

Same backtrace (just a bit different line numbers) with all branches.



[2009-05-26 05:24:23] scott...@php.net

I can confirm here on OSX.

#0  0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:1088
1088return (((uchar *)value)[1]  8) | ((uchar *)value)[0];
(gdb) bt
#0  0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:1088
#1  0x00037a01 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffef8c,
dir_start=0x7100b1 Address 0x7100b1 out of bounds,
offset_base=0x3100a8 II*, IFDlength=126, displacement=12,
section_index=3) at /Users/scott/dev/php5_2/ext/exif/exif.c:3140
#2  0x00037d92 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffef8c,
CharBuf=0x3100a8 II*, length=126, displacement=12) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3221
#3  0x00037e92 in exif_process_APP1 (ImageInfo=0xbfffef8c,
CharBuf=0x3100a0 , length=134, displacement=4) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3246
#4  0x000384d2 in exif_scan_JPEG_header (ImageInfo=0xbfffef8c) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3385
#5  0x000393c4 in exif_scan_FILE_header (ImageInfo=0xbfffef8c) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3757
#6  0x0003a073 in exif_read_file (ImageInfo=0xbfffef8c,
FileName=0x30d2d4 hello-s148.jpeg, read_thumbnail=0, read_all=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3902




[2009-05-25 20:49:59] phpbug dot exif at sub dot noloop dot net

That's odd. I'm getting 100% reproducible crash on both the latest 5.2
cvs snapshot, as well as the php build included in Debian Linux 5.0.1
(stable) (which is 5.2.6+some debian patches)

I'm using Linux 2.6.29.4, Debian 5.0.1, gcc version 4.3.2 (Debian
4.3.2-1.1) on an i686 (32bit) machine with 3gb ram. 

To compile, I did:

'./configure'  '--prefix=/home/frode/temp/z/zinst3' '--disable-all'
'--enable-exif'
make cli

Are you running on 64bit, or perhaps some other distro with a different
version of gcc etc?



[2009-05-25 19:59:23] il...@php.net

I am getting the following error messages, but no crash:

Warning: exif_read_data(hello-s148.jpeg): Illegal IFD size: x4B + 2

+ x*12 = x4B  x007E in exif.php on line 2

Warning: exif_read_data(hello-s148.jpeg): Error reading from file: 
got=x08B4(=2228) != itemlen-2=x1FFE(=8190) in exif.php on line 2

Warning: exif_read_data(hello-s148.jpeg): Invalid JPEG file in exif.php

on line 2





[2009-05-24 20:58:14] phpbug dot exif at sub dot noloop dot net

Description:

There seems to be a problem in exif_read_data(), where some fields
representing offsets(?) are taken directly from the file without being
validated, resulting in a segmentation fault.

I originally found this issue by fooling around with the zzuf fuzzer,
and reported a very similar bug in the jhead exif utility at
http://bugs.debian.org/530401

Original image can be found at:
http://www.noloop.net/bugs/php/001-exif/hello.jpeg
Corrupted image can be found at:
http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg


Reproduce code:
---
?php
 var_dump(exif_read_data($_SERVER['argv'][1], array(FILE, COMPUTED,
ANY_TAG) ));

Expected result:

Dump of exif data if possible, or FALSE (since the jpeg file is indeed
corrupt)

Actual result:
--
Segmentation fault.

Quick GDB dump:
(gdb) run
Starting program:
/home/frode/temp/z/z3/php5.2-200905241830/sapi/cli/php
/home/frode/temp/z/s.php /home/frode/temp/z/a-s6.jpeg

Program received signal SIGSEGV, Segmentation fault.
0x0808bcd3 in exif_process_IFD_in_JPEG (ImageInfo=0xbfc893b8, 
dir_start=0x92f76c0 Address 0x92f76c0 out of bounds,
offset_base=0x8ef76b8 II*, IFDlength=15055, 
displacement=30, section_index=3) at
/home/frode/temp/z/z3/php5.2-200905241830/ext/exif/exif.c:1088
1088return (((uchar *)value)[1]  8) | ((uchar
*)value)[0];
(gdb) up
#1  0x0808e6ca in exif_read_file (ImageInfo=0xbfc893b8, FileName=value
optimized out, 
read_thumbnail=value optimized out, read_all=0)
at 

#48414 [NEW]: The FastCGI process exited unexpectedly

2009-05-28 Thread dannyoneill at ntlworld dot com
From: dannyoneill at ntlworld dot com
Operating system: Windows 2003 Server
PHP version:  5.2.9
PHP Bug Type: Reproducible crash
Bug description:  The FastCGI process exited unexpectedly

Description:

On a freshly built (and existing) Windows server with PHP 5.2.9 and
FastCGI the following error occurs when trying to access phpMyAdmin when
register_globals is set to on;

---
FastCGI Error
The FastCGI Handler was unable to process the request.

Error Details:

* The FastCGI process exited unexpectedly
* Error Number: -1073741819 (0xc005).
* Error Description: Unknown Error

HTTP Error 500 - Server Error.
Internet Information Services (IIS)
-

I have built a fresh server and can re-create this each time. This only
occurs when using fastcgi.

Reproduce code:
---
Standard install of phpMyAdmin

Expected result:

Sucessful logon

Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.

Error Details:

* The FastCGI process exited unexpectedly
* Error Number: -1073741819 (0xc005).
* Error Description: Unknown Error

HTTP Error 500 - Server Error.
Internet Information Services (IIS)

-- 
Edit bug report at http://bugs.php.net/?id=48414edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48414r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48414r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48414r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48414r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48414r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48414r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48414r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48414r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48414r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48414r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48414r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48414r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48414r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48414r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48414r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48414r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48414r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48414r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48414r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48414r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48414r=mysqlcfg



#48378 [Ver-Csd]: exif_read_data() segfaults on certain corrupted .jpeg files

2009-05-28 Thread pajoye
 ID:   48378
 Updated by:   paj...@php.net
 Reported By:  phpbug dot exif at sub dot noloop dot net
-Status:   Verified
+Status:   Closed
 Bug Type: EXIF related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-27)
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-28 12:49:36] il...@php.net

On 64 bit linux I get no crash and no complaints from valgrind either.



[2009-05-27 19:05:13] j...@php.net

Verified with proper test script, this function never accepted array 
parameters:

?php
exif_read_data(
http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg;, 
FILE,COMPUTED,ANY_TAG
);

Same backtrace (just a bit different line numbers) with all branches.



[2009-05-26 05:24:23] scott...@php.net

I can confirm here on OSX.

#0  0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:1088
1088return (((uchar *)value)[1]  8) | ((uchar *)value)[0];
(gdb) bt
#0  0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:1088
#1  0x00037a01 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffef8c,
dir_start=0x7100b1 Address 0x7100b1 out of bounds,
offset_base=0x3100a8 II*, IFDlength=126, displacement=12,
section_index=3) at /Users/scott/dev/php5_2/ext/exif/exif.c:3140
#2  0x00037d92 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffef8c,
CharBuf=0x3100a8 II*, length=126, displacement=12) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3221
#3  0x00037e92 in exif_process_APP1 (ImageInfo=0xbfffef8c,
CharBuf=0x3100a0 , length=134, displacement=4) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3246
#4  0x000384d2 in exif_scan_JPEG_header (ImageInfo=0xbfffef8c) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3385
#5  0x000393c4 in exif_scan_FILE_header (ImageInfo=0xbfffef8c) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3757
#6  0x0003a073 in exif_read_file (ImageInfo=0xbfffef8c,
FileName=0x30d2d4 hello-s148.jpeg, read_thumbnail=0, read_all=0) at
/Users/scott/dev/php5_2/ext/exif/exif.c:3902




[2009-05-25 20:49:59] phpbug dot exif at sub dot noloop dot net

That's odd. I'm getting 100% reproducible crash on both the latest 5.2
cvs snapshot, as well as the php build included in Debian Linux 5.0.1
(stable) (which is 5.2.6+some debian patches)

I'm using Linux 2.6.29.4, Debian 5.0.1, gcc version 4.3.2 (Debian
4.3.2-1.1) on an i686 (32bit) machine with 3gb ram. 

To compile, I did:

'./configure'  '--prefix=/home/frode/temp/z/zinst3' '--disable-all'
'--enable-exif'
make cli

Are you running on 64bit, or perhaps some other distro with a different
version of gcc etc?



[2009-05-25 19:59:23] il...@php.net

I am getting the following error messages, but no crash:

Warning: exif_read_data(hello-s148.jpeg): Illegal IFD size: x4B + 2

+ x*12 = x4B  x007E in exif.php on line 2

Warning: exif_read_data(hello-s148.jpeg): Error reading from file: 
got=x08B4(=2228) != itemlen-2=x1FFE(=8190) in exif.php on line 2

Warning: exif_read_data(hello-s148.jpeg): Invalid JPEG file in exif.php

on line 2





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/48378

-- 
Edit this bug report at http://bugs.php.net/?id=48378edit=1



#48414 [Opn-Fbk]: The FastCGI process exited unexpectedly

2009-05-28 Thread pajoye
 ID:   48414
 Updated by:   paj...@php.net
 Reported By:  dannyoneill at ntlworld dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2003 Server
 PHP Version:  5.2.9
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2009-05-28 13:57:01] dannyoneill at ntlworld dot com

Description:

On a freshly built (and existing) Windows server with PHP 5.2.9 and
FastCGI the following error occurs when trying to access phpMyAdmin when
register_globals is set to on;

---
FastCGI Error
The FastCGI Handler was unable to process the request.

Error Details:

* The FastCGI process exited unexpectedly
* Error Number: -1073741819 (0xc005).
* Error Description: Unknown Error

HTTP Error 500 - Server Error.
Internet Information Services (IIS)
-

I have built a fresh server and can re-create this each time. This only
occurs when using fastcgi.

Reproduce code:
---
Standard install of phpMyAdmin

Expected result:

Sucessful logon

Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.

Error Details:

* The FastCGI process exited unexpectedly
* Error Number: -1073741819 (0xc005).
* Error Description: Unknown Error

HTTP Error 500 - Server Error.
Internet Information Services (IIS)





-- 
Edit this bug report at http://bugs.php.net/?id=48414edit=1



#48415 [NEW]: PHP doesn't read the configurations propertly

2009-05-28 Thread nicky_l at hotmail dot fr
From: nicky_l at hotmail dot fr
Operating system: Windows XP Pro SP3
PHP version:  5.2.9
PHP Bug Type: Apache2 related
Bug description:  PHP doesn't read the configurations propertly

Description:

Hi,

I am encountering exactly the same problems as those mentionned below by
rafael dot amador at gmail dot com
exept that I am using an APACHE 2.2 server.

So UP please.
If anyone in the team or any experimented developer here has got any idea
of how to deal with this issue, will much apperciated

Thanks inn advance




[26 Jun 2006 6:30pm UTC] rafael dot amador at gmail dot com

Description:

in IIS 5.1, PHP ISAPI Module and .Net framework 2.0 installed, following
instructions from install.php, PHP doesn't read the options in file
php.ini 

if i put php.ini in c:\php\ (the webserver init php but you can't
configure any option, php don't load any modules and in phpinfo() page
you look strange values)

example:
 Configuration File (php.ini) Path: C:\WINDOWS must be
c:\php\php.ini

extension_dir:  C:\php5   C:\php5 in phpinfo()
in php.ini the value is: extension_dir = c:/php/ext/

i've PATH pointing to c:\php\, my document_root is well configured

and i put php.ini in other place php shows message No input file
specified.

i'm experimenting the Bug #37843
and other bug (if you put php5isapi.dll in ISAPI Filters when you
shutdown the server ISS crash allways)

Reproduce code:
---
?
phpinfo();
?

Expected result:

that my changes to php.ini are reflected in phpinfo()

Actual result:
--
php shows strange parameter configurations (i can't load any module) 

[26 Jun 2006 6:46pm UTC] tony2...@php.net

Did you add c:\php to your PATH environment variable?

[26 Jun 2006 6:50pm UTC] rafael dot amador at gmail dot com

yeah sure i've checked the PATH enviroment variable and c:\php is
present

[26 Jun 2006 6:52pm UTC] tony2...@php.net

And did you reboot after that?

[26 Jun 2006 6:54pm UTC] rafael dot amador at gmail dot com

sure i followed all instructions

[26 Jun 2006 9:09pm UTC] rafael dot amador at gmail dot com

i rebooted my server and again i've the same result

[27 Jun 2006 2:16am UTC] rafael dot amador at gmail dot com

i configured the php file with the registry entry pointing to it and
didn't work but if i comment the doc_root option in php.ini all works
WELL.

a couple of questions come to me now:

why the windows PATH method doesn't works?

why the registry method works only with doc_root disabled?

i saw a lot of bugs that have similar behavior. check this beacuse if
isn't a bug then isn't documentated.

[27 Sep 2006 7:25am UTC] mcloudteo at hotmail dot com

Do this:

 * Go to Control Panel and open the System icon (Start - Settings
-
   Control Panel - System, or just Start - Control Panel -
System
   for Windows XP/2003)
 * Go to the Advanced tab
 * Click on the 'Environment Variables' button
 * Look into the 'System variables' pane
 * Click on 'New' and enter 'PHPRC' as the variable name and the
   directory where php.ini is located as the variable value (e.g.
   C:\php)
 * Press OK and restart your computer

[22 Oct 2006 8:45pm UTC] rafael dot amador at gmail dot com

i've perfectly told that any other method works, with this statement i
mean any other method DOESN'T WORK. and  by the way i'm reporting a BUG
i've a work arround but the bug still remains in the code. 

i've solved this with the register method now i've my server working
with this method but the point here is that the PATH method doesn't work
... 

i've spend a lot of time reporting this bug and following the progress
of it. i'm waiting that anyone there (Zend-PHP developer staff) take
this seriously don't give me a pretext to close this bug. This danm bug
is giving headaches to more than a couple of IT admins. 

i'm very annoyed about the response time showing a profesionless
attitude ... sorry guys but it's the truth

[16 Apr 2007 8:12pm UTC] sni...@php.net

It's not quite clear what does not work for you:

a) Are you able to run PHP scripts at all?
b) Does removing 'doc_root' setting from php.ini really fix this?
c) How about running PHP as FastCGI? (I prefer this myself, running PHP
as module is so 90's :)

[16 Apr 2007 9:08pm UTC] rafael dot amador at gmail dot com

ok 

the point here that using ISAPI module in IIS and trying to use the Path
method to configure the module, makes that PHP doesn't recognize
propertly the php.ini path and its configuration that situation makes
that php doesn't load any additional modules including mysqli and any
others...

becoming any php script in a useless piece of code... stills run but is
not capable to call any functions of any module...

i hope that this explanation make you clear what i'm reporting here...

response to the questions

a) with the specified conditions, yes, but without any configuration
available no additional modules, php scripts become useless 

#48415 [Opn-Bgs]: PHP doesn't read the configurations propertly

2009-05-28 Thread jani
 ID:   48415
 Updated by:   j...@php.net
 Reported By:  nicky_l at hotmail dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP Pro SP3
 PHP Version:  5.2.9
 New Comment:

Use fastcgi with IIS. See http://php.iis.net/ for more.
If you have some problems with Apache2, please submit a report that has
ONLY that problem in it.


Previous Comments:


[2009-05-28 15:47:38] nicky_l at hotmail dot fr

Description:

Hi,

I am encountering exactly the same problems as those mentionned below
by rafael dot amador at gmail dot com
exept that I am using an APACHE 2.2 server.

So UP please.
If anyone in the team or any experimented developer here has got any
idea of how to deal with this issue, will much apperciated

Thanks inn advance




[26 Jun 2006 6:30pm UTC] rafael dot amador at gmail dot com

Description:

in IIS 5.1, PHP ISAPI Module and .Net framework 2.0 installed,
following
instructions from install.php, PHP doesn't read the options in file
php.ini 

if i put php.ini in c:\php\ (the webserver init php but you can't
configure any option, php don't load any modules and in phpinfo() page
you look strange values)

example:
 Configuration File (php.ini) Path: C:\WINDOWS must be
c:\php\php.ini

extension_dir:  C:\php5   C:\php5 in phpinfo()
in php.ini the value is: extension_dir = c:/php/ext/

i've PATH pointing to c:\php\, my document_root is well configured

and i put php.ini in other place php shows message No input file
specified.

i'm experimenting the Bug #37843
and other bug (if you put php5isapi.dll in ISAPI Filters when you
shutdown the server ISS crash allways)

Reproduce code:
---
?
phpinfo();
?

Expected result:

that my changes to php.ini are reflected in phpinfo()

Actual result:
--
php shows strange parameter configurations (i can't load any module) 

[26 Jun 2006 6:46pm UTC] tony2...@php.net

Did you add c:\php to your PATH environment variable?

[26 Jun 2006 6:50pm UTC] rafael dot amador at gmail dot com

yeah sure i've checked the PATH enviroment variable and c:\php is
present

[26 Jun 2006 6:52pm UTC] tony2...@php.net

And did you reboot after that?

[26 Jun 2006 6:54pm UTC] rafael dot amador at gmail dot com

sure i followed all instructions

[26 Jun 2006 9:09pm UTC] rafael dot amador at gmail dot com

i rebooted my server and again i've the same result

[27 Jun 2006 2:16am UTC] rafael dot amador at gmail dot com

i configured the php file with the registry entry pointing to it and
didn't work but if i comment the doc_root option in php.ini all works
WELL.

a couple of questions come to me now:

why the windows PATH method doesn't works?

why the registry method works only with doc_root disabled?

i saw a lot of bugs that have similar behavior. check this beacuse if
isn't a bug then isn't documentated.

[27 Sep 2006 7:25am UTC] mcloudteo at hotmail dot com

Do this:

 * Go to Control Panel and open the System icon (Start - Settings
-
   Control Panel - System, or just Start - Control Panel -
System
   for Windows XP/2003)
 * Go to the Advanced tab
 * Click on the 'Environment Variables' button
 * Look into the 'System variables' pane
 * Click on 'New' and enter 'PHPRC' as the variable name and the
   directory where php.ini is located as the variable value (e.g.
   C:\php)
 * Press OK and restart your computer

[22 Oct 2006 8:45pm UTC] rafael dot amador at gmail dot com

i've perfectly told that any other method works, with this statement i
mean any other method DOESN'T WORK. and  by the way i'm reporting a
BUG
i've a work arround but the bug still remains in the code. 

i've solved this with the register method now i've my server working
with this method but the point here is that the PATH method doesn't
work
... 

i've spend a lot of time reporting this bug and following the progress
of it. i'm waiting that anyone there (Zend-PHP developer staff) take
this seriously don't give me a pretext to close this bug. This danm
bug
is giving headaches to more than a couple of IT admins. 

i'm very annoyed about the response time showing a profesionless
attitude ... sorry guys but it's the truth

[16 Apr 2007 8:12pm UTC] sni...@php.net

It's not quite clear what does not work for you:

a) Are you able to run PHP scripts at all?
b) Does removing 'doc_root' setting from php.ini really fix this?
c) How about running PHP as FastCGI? (I prefer this myself, running
PHP
as module is so 90's :)

[16 Apr 2007 9:08pm UTC] rafael dot amador at gmail dot com

ok 

the point here that using ISAPI module in IIS and trying to use the
Path
method to configure the module, makes that PHP doesn't recognize
propertly the php.ini path and its configuration that situation makes
that php doesn't load any additional modules including mysqli and any

#43189 [Opn]: Fails to link iconv

2009-05-28 Thread philip
 ID:   43189
 Updated by:   phi...@php.net
 Reported By:  meh at mailinator dot com
 Status:   Open
 Bug Type: ICONV related
 Operating System: Mac OS X 10.5
 PHP Version:  5.3CVS-2007-11-04 (snap)
 New Comment:

For me, the following solution worked:

http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-
compiling-php-528/

Which involves moving around $(MH_BUNDLE_FLAGS). Looks like a different

yet related bug however, but 


Previous Comments:


[2009-05-24 15:54:54] meh at mailinator dot com

It still fails for me in php5.3-200905241430.

This workaround still necessary:
sudo mv /usr/include/iconv.h /usr/include/iconv.h.leo_orig
sudo ln -s /sw/include/iconv.h /usr/include/iconv.h
rm ext/iconv/*.*o
make



[2009-04-30 13:03:17] scott...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2009-04-24 17:38:06] richard dot sentino at mindginative dot com

This configure option worked for me:

--with-iconv=/opt/local

(Mac OS 10.5.6, PHP 5.2.9, iconv installed in /opt/local using
macports)

but it doesn't work with this configure option :

--with-iconv=shared,/opt/local

the configure passed and make passed but iconv won't show up when I do
php -m



[2009-03-27 06:26:43] senz at senz dot su

Changing --with-iconv-dir to --with-iconv=shared,/opt/local
solve it on my system.

/opt/local = macports with iconv



[2009-03-27 06:10:22] senz at senz dot su

To scott...@php.net:
here's my config.log from compilation with error.
iconv compiled by macports. --with-iconv-dir=shared,/opt/local and
static both failed.
http://rapidshare.com/files/214033749/config.log.html
i also send a copy on your email.



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/43189

-- 
Edit this bug report at http://bugs.php.net/?id=43189edit=1



#48413 [Opn-Fbk]: floating-point formats on 64 bit systems

2009-05-28 Thread jani
 ID:   48413
 Updated by:   j...@php.net
 Reported By:  vgabor at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Math related
 Operating System: Linux x86_64
 PHP Version:  5.2.9
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-05-28 12:41:27] vgabor at gmail dot com

Description:

This in not quite bug, I think everybody know well the possible
float-integer conversation problems on the usual 32 bit systems, but the
64 bit systems give us some new ones.

On 64 bit, the float becomes actually less precise then the integer,
because the binary64 (double) floating point format what the PHP using
is up to 52+1 bits while the integer 63+1 bit. Most of the mathematical
functions are using and convert the numbers to float which historically
give better result on 32 bit system (52+1 bit versus 31+1 bit) but with
64 bit integer thats unfortunately not the case (52+1 bit instead of
63+1 bit)

Solving this problem I would recommend to introduce in the PHP the
binary128 (quad) floating point format from the latest floating-point
arithmetic standard (IEEE 754-2008, last year) which would give us 112+1
bits precision.

Reproduce code:
---
Just a quick example when it comes to numbers above 52+1 bit (the /
operator convert the result to float which leads to precision loss on 64
bit systems):

ini_set('precision', 99);
$X=4485476582; 

  $Y=4485476608;

echo ($X/10*10) === $X: .((int)($X/10*10) === $X ? 'true' :
'false').\n;
echo ($X/10*10) === $Y: .((int)($X/10*10) === $Y ? 'true' :
'false').\n\n;

echo ($X).\n;
echo ($X/10).\n;
echo ($X/10*10).\n;







-- 
Edit this bug report at http://bugs.php.net/?id=48413edit=1



#48413 [Fbk]: floating-point formats on 64 bit systems

2009-05-28 Thread jani
 ID:   48413
 Updated by:   j...@php.net
 Reported By:  vgabor at gmail dot com
 Status:   Feedback
 Bug Type: Math related
 Operating System: Linux x86_64
 PHP Version:  5.2.9
 New Comment:

And when you post example scripts, put ?php ? tags around and also
provide the expected / actual outputs.


Previous Comments:


[2009-05-28 16:43:12] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-05-28 12:41:27] vgabor at gmail dot com

Description:

This in not quite bug, I think everybody know well the possible
float-integer conversation problems on the usual 32 bit systems, but the
64 bit systems give us some new ones.

On 64 bit, the float becomes actually less precise then the integer,
because the binary64 (double) floating point format what the PHP using
is up to 52+1 bits while the integer 63+1 bit. Most of the mathematical
functions are using and convert the numbers to float which historically
give better result on 32 bit system (52+1 bit versus 31+1 bit) but with
64 bit integer thats unfortunately not the case (52+1 bit instead of
63+1 bit)

Solving this problem I would recommend to introduce in the PHP the
binary128 (quad) floating point format from the latest floating-point
arithmetic standard (IEEE 754-2008, last year) which would give us 112+1
bits precision.

Reproduce code:
---
Just a quick example when it comes to numbers above 52+1 bit (the /
operator convert the result to float which leads to precision loss on 64
bit systems):

ini_set('precision', 99);
$X=4485476582; 

  $Y=4485476608;

echo ($X/10*10) === $X: .((int)($X/10*10) === $X ? 'true' :
'false').\n;
echo ($X/10*10) === $Y: .((int)($X/10*10) === $Y ? 'true' :
'false').\n\n;

echo ($X).\n;
echo ($X/10).\n;
echo ($X/10*10).\n;







-- 
Edit this bug report at http://bugs.php.net/?id=48413edit=1



#48365 [Opn-Fbk]: glob() function returns empty array

2009-05-28 Thread jani
 ID:   48365
 Updated by:   j...@php.net
 Reported By:  peter dot chen at itg dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: sparc-sol2.10
 PHP Version:  5.2.9
 New Comment:

Exactly what Solaris version are you on?
Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/));'



Previous Comments:


[2009-05-27 23:05:14] peter dot chen at itg dot com

My apologies, I did not read all the instructions. 

Is there a flag I needed to enable when building php?

As for the code, I mistakenly left the ';' that caused the parse error.
The code should be as follows: 

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*'));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



[2009-05-23 17:03:08] j...@php.net

You obviously didn't follow the url provided in the email. Please, do 
not Add Comment to your own report, use the Edit Submission (where

the link in the email points too. 

And now, please provide the code that actually causes the problem. That

code works fine everywhere.



[2009-05-23 10:35:41] carsten_sttgt at gmx dot de

 print_r(glob($path . '*.*';));

This line give you a parse error. Must be:
| print_r(glob($path . '*.*'));

Apart from this, the code is working for me (Win,BSD).

BTW:
 [0] = .
 [1] = ..
 [2] = authtest

With your code, this can't be part of the result from glob().

Regards,
Carsten



[2009-05-22 21:09:23] peter dot chen at itg dot com

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*';));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



[2009-05-22 19:43:37] j...@php.net

Please provide proper example script.



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/48365

-- 
Edit this bug report at http://bugs.php.net/?id=48365edit=1



#48365 [Fbk]: glob() function returns empty array

2009-05-28 Thread jani
 ID:   48365
 Updated by:   j...@php.net
 Reported By:  peter dot chen at itg dot com
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: sparc-sol2.10
 PHP Version:  5.2.9
 New Comment:

Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/*));'



Previous Comments:


[2009-05-28 16:49:23] j...@php.net

Exactly what Solaris version are you on?
Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/));'




[2009-05-27 23:05:14] peter dot chen at itg dot com

My apologies, I did not read all the instructions. 

Is there a flag I needed to enable when building php?

As for the code, I mistakenly left the ';' that caused the parse error.
The code should be as follows: 

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*'));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



[2009-05-23 17:03:08] j...@php.net

You obviously didn't follow the url provided in the email. Please, do 
not Add Comment to your own report, use the Edit Submission (where

the link in the email points too. 

And now, please provide the code that actually causes the problem. That

code works fine everywhere.



[2009-05-23 10:35:41] carsten_sttgt at gmx dot de

 print_r(glob($path . '*.*';));

This line give you a parse error. Must be:
| print_r(glob($path . '*.*'));

Apart from this, the code is working for me (Win,BSD).

BTW:
 [0] = .
 [1] = ..
 [2] = authtest

With your code, this can't be part of the result from glob().

Regards,
Carsten



[2009-05-22 21:09:23] peter dot chen at itg dot com

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*';));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



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/48365

-- 
Edit this bug report at http://bugs.php.net/?id=48365edit=1



#48360 [Bgs-Opn]: urlencode and rawurlencode are not RFC-1738 compliant

2009-05-28 Thread lbarnaud
 ID:   48360
 Updated by:   lbarn...@php.net
 Reported By:  martin2007 at laposte dot net
-Status:   Bogus
+Status:   Open
 Bug Type: URL related
 Operating System: Linux
 PHP Version:  5.2.9


Previous Comments:


[2009-05-22 11:47:07] lbarn...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

From the RFC:
   Usually a URL has the same interpretation when an octet is
   represented by a character and when it encoded. [...]

   [...] characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.


This means urlencode() may encode everything, including alphanumerics,
and still be RFC1738 compliant.

www.example.com/$!*'(), === www.example.com/%24%21%2A%27%28%29%2C
www.example.com/%24%21%2A%27%28%29%2C === www.example.com/$!*'(),

For your experiment, you may want to try linking twice times the same
page, encoded differently. Then check if Google indexes the page twice
with two different URLs.

Search engines are smart enough to canonicalize every URL they have to
work with. Two URLs encoded differently are still the same.



[2009-05-22 10:17:17] martin2007 at laposte dot net

Description:

urlencode and rawurlencode are not RFC-1738 compliant.

RFC-1738 states:
 Thus, only alphanumerics, the special characters $-_.+!*'(),, and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
Later on, the grammar is as follows:

unreserved = alpha | digit | safe | extra
safe   = $ | - | _ | . | +
extra  = ! | * | ' | ( | ) | ,


However, urlencode and rawurlencode encode $!*'(),

Note that, except for $ and ,, this is also true for RFC-2396
(URI).

The main problem is that Google uses another encoding scheme. When you
have URLs containing these characters, your weblogs contain several
different URLs for the same resource. It might also confuse some web
server implementations.


See: http://www.monperrus.net/martin/googenc/


Reproduce code:
---
echo urlencode($!*'(),);
echo rawurlencode($!*'(),);

Expected result:

$!*'(),
$!*'(),

Actual result:
--
%24%21%2A%27%28%29%2C
%24%21%2A%27%28%29%2C





-- 
Edit this bug report at http://bugs.php.net/?id=48360edit=1



#48416 [NEW]: Memleak in ereg() and eregi() functions

2009-05-28 Thread bmorel at ssi dot fr
From: bmorel at ssi dot fr
Operating system: CentOS 5.3
PHP version:  5.2.9
PHP Bug Type: Regexps related
Bug description:  Memleak in ereg() and eregi() functions

Description:

When repeating an ereg() or eregi() on different patterns, the memory
usage of httpd (or php if executed from the command-line) gets huge (about
1GB for the example below) for the time the script executes, then the
memory is freed.
During this time, the memory_get_usage() stays normal, and php's memory
limit doesn't trigger.

When repeating the ereg() with the same pattern each time, the memory
usage stays normal; this happens only when repeating with a different
pattern each time.

Verified on CentOS with PHP 5.2.6  5.2.9
Verified on Windows XP with PHP 5.2.8

Reproduce code:
---
?php
for ($i=0;$i100;$i++) ereg($i,test);
?

Expected result:

Memory usage staying low.

Actual result:
--
Memory usage as shown by top -d 1 gets huge.

-- 
Edit bug report at http://bugs.php.net/?id=48416edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48416r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48416r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48416r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48416r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48416r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48416r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48416r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48416r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48416r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48416r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48416r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48416r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48416r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48416r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48416r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48416r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48416r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48416r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48416r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48416r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48416r=mysqlcfg



#48416 [Opn-Fbk]: Memleak in ereg() and eregi() functions

2009-05-28 Thread scottmac
 ID:   48416
 Updated by:   scott...@php.net
 Reported By:  bmorel at ssi dot fr
-Status:   Open
+Status:   Feedback
 Bug Type: Regexps related
 Operating System: CentOS 5.3
 PHP Version:  5.2.9
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Pretty sure this is due to the regular expression cache we have, each
unique regular expression is cached so we don't keep compiling it but
there is no cap on the number we store.

Can you try a 5.3 snapshot, I think we switched from using ereg to pcre
with 5.3.


Previous Comments:


[2009-05-28 16:57:59] bmorel at ssi dot fr

Description:

When repeating an ereg() or eregi() on different patterns, the memory
usage of httpd (or php if executed from the command-line) gets huge
(about 1GB for the example below) for the time the script executes, then
the memory is freed.
During this time, the memory_get_usage() stays normal, and php's memory
limit doesn't trigger.

When repeating the ereg() with the same pattern each time, the memory
usage stays normal; this happens only when repeating with a different
pattern each time.

Verified on CentOS with PHP 5.2.6  5.2.9
Verified on Windows XP with PHP 5.2.8

Reproduce code:
---
?php
for ($i=0;$i100;$i++) ereg($i,test);
?

Expected result:

Memory usage staying low.

Actual result:
--
Memory usage as shown by top -d 1 gets huge.





-- 
Edit this bug report at http://bugs.php.net/?id=48416edit=1



#48417 [NEW]: Missing config.w32.h

2009-05-28 Thread php at schubec dot com
From: php at schubec dot com
Operating system: Windows
PHP version:  5.3.0RC2
PHP Bug Type: Compile Failure
Bug description:  Missing config.w32.h

Description:

File main/config.w32.h in PHP 5.3.0RC2 is missing.
The file is required because Zend/zend_config.w32.h includes it.

The missing file causes that PHP cannot be comiled.

Compiler: VC6
OS: WindowsXP

PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up.

Reproduce code:
---
Tryp compile PHP under Windows.

Expected result:

PHP able to compile :-)

Actual result:
--
PHP unable to compile :-(

-- 
Edit bug report at http://bugs.php.net/?id=48417edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48417r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48417r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48417r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48417r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48417r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48417r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48417r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48417r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48417r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48417r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48417r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48417r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48417r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48417r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48417r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48417r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48417r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48417r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48417r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48417r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48417r=mysqlcfg



#48417 [Opn-Bgs]: Missing config.w32.h

2009-05-28 Thread pajoye
 ID:   48417
 Updated by:   paj...@php.net
 Reported By:  php at schubec dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Windows
 PHP Version:  5.3.0RC2
 New Comment:

it is generated at configure time.


Previous Comments:


[2009-05-28 17:39:51] php at schubec dot com

Description:

File main/config.w32.h in PHP 5.3.0RC2 is missing.
The file is required because Zend/zend_config.w32.h includes it.

The missing file causes that PHP cannot be comiled.

Compiler: VC6
OS: WindowsXP

PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up.

Reproduce code:
---
Tryp compile PHP under Windows.

Expected result:

PHP able to compile :-)

Actual result:
--
PHP unable to compile :-(





-- 
Edit this bug report at http://bugs.php.net/?id=48417edit=1



#45289 [NoF]: Cannot use prepared statements and fetch_row together

2009-05-28 Thread uw
 ID:   45289
 Updated by:   u...@php.net
 Reported By:  mike dot benza at rice dot edu
 Status:   No Feedback
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.2.4
 New Comment:

I think its bogus. Wrong use of the API. The critical part here is that
you get a result set at all...


Previous Comments:


[2009-05-15 19:55:28] jochen dot wiedmann at gmail dot com

I have checked the latest snapshot (php5.2-200905151830), whether the
problem still persists by using the script below. (Should be easy to
derive a .phpt file from it.)

?php
  $mysqli = mysqli_init();
  $mysqli-real_connect(localhost, root, null, 'test');
  if (mysqli_connect_errno()) {
printf(Connect failed: %s\n, mysqli_connect_error());
exit();
  }
  $mysqli-query(DROP TABLE IF EXISTS prep_and_fetch_row)
or die($mysqli-error);
  $mysqli-query(CREATE TABLE prep_and_fetch_row(id BIGINT NOT NULL
PRIMARY KEY, name VARCHAR(64) NOT NULL))
or die($mysqli-error);
  $mysqli-query(INSERT INTO prep_and_fetch_row (id, name) VALUES (1,
'abc'))
or die($mysqli-error);
  $stmt = $mysqli-prepare(SELECT * FROM prep_and_fetch_row WHERE
id=?)
or die($mysqli-error);
  $id = 1;
  $stmt-bind_param(i, $id)  or die($mysqli-error);
  $stmt-execute() or die($mysqli-error);
  $result = $mysqli-use_result() or die($mysqli-error);
  while ($row = $result-fetch_row()) {
print - result row ---\n;
print_r($row);
  }
  print - no more results ---\n;

  $mysqli-query(DROP TABLE prep_and_fetch_row) or
die($mysqli-error);
  $mysqli-close();
?

Expected output: Something like

- result row ---
Array
(
[0] = int(1)
[1] = string(3) abc
)
- no more results ---

Actual output:

- result row ---
Array
(
[0] = 
[1] = 
)
- no more results ---

I'd consider this to be a clear bug.



[2009-05-15 13:39:22] jochen dot wiedmann at gmail dot com

I have the same problem with PHP 5.2.6, as delivered with Fedora 10
Linux.



[2008-07-22 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-07-14 21:05:49] 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





[2008-07-11 08:54:43] omolano at PLEASENOSPAMinicia dot es

I've also had this problem. In my case I was trying to use
PDO::FETCH_ASSOC on a prepared statement and the database was SQLite 3
based. I also got null values, like the above poster, not garbage.



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/45289

-- 
Edit this bug report at http://bugs.php.net/?id=45289edit=1



#48416 [Com]: Memleak in ereg() and eregi() functions

2009-05-28 Thread bmorel at ssi dot fr
 ID:   48416
 Comment by:   bmorel at ssi dot fr
 Reported By:  bmorel at ssi dot fr
 Status:   Feedback
 Bug Type: Regexps related
 Operating System: CentOS 5.3
 PHP Version:  5.2.9
 New Comment:

Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev :
php5.3-200905281630).

The cache seems to be a good explanation, but it this a good idea ?
I have millions of ereg()s done when I parse huge XML files (several
GB), and my memory usage goes too high. I had to replace all my ereg()s
with preg_match()s.

Thanks,
Ben


Previous Comments:


[2009-05-28 17:30:21] scott...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Pretty sure this is due to the regular expression cache we have, each
unique regular expression is cached so we don't keep compiling it but
there is no cap on the number we store.

Can you try a 5.3 snapshot, I think we switched from using ereg to pcre
with 5.3.



[2009-05-28 16:57:59] bmorel at ssi dot fr

Description:

When repeating an ereg() or eregi() on different patterns, the memory
usage of httpd (or php if executed from the command-line) gets huge
(about 1GB for the example below) for the time the script executes, then
the memory is freed.
During this time, the memory_get_usage() stays normal, and php's memory
limit doesn't trigger.

When repeating the ereg() with the same pattern each time, the memory
usage stays normal; this happens only when repeating with a different
pattern each time.

Verified on CentOS with PHP 5.2.6  5.2.9
Verified on Windows XP with PHP 5.2.8

Reproduce code:
---
?php
for ($i=0;$i100;$i++) ereg($i,test);
?

Expected result:

Memory usage staying low.

Actual result:
--
Memory usage as shown by top -d 1 gets huge.





-- 
Edit this bug report at http://bugs.php.net/?id=48416edit=1



#48417 [Bgs]: Missing config.w32.h

2009-05-28 Thread php at schubec dot com
 ID:   48417
 User updated by:  php at schubec dot com
 Reported By:  php at schubec dot com
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Windows
 PHP Version:  5.3.0RC2
 New Comment:

Hi!

it is generated at configure time.
Okay... thank you.

But why was it part of the PHP 5.2.9 sourcecode download then?
So the bug is not that it is missing in 5.3.0RC2 but that it was part
of 5.2.9, right?

Thank you!


Previous Comments:


[2009-05-28 17:41:36] paj...@php.net

it is generated at configure time.



[2009-05-28 17:39:51] php at schubec dot com

Description:

File main/config.w32.h in PHP 5.3.0RC2 is missing.
The file is required because Zend/zend_config.w32.h includes it.

The missing file causes that PHP cannot be comiled.

Compiler: VC6
OS: WindowsXP

PS: The file was part of PHP 5.2.9 Sourcecode, I just looked that up.

Reproduce code:
---
Tryp compile PHP under Windows.

Expected result:

PHP able to compile :-)

Actual result:
--
PHP unable to compile :-(





-- 
Edit this bug report at http://bugs.php.net/?id=48417edit=1



#48365 [Fbk-Opn]: glob() function returns empty array

2009-05-28 Thread peter dot chen at itg dot com
 ID:   48365
 User updated by:  peter dot chen at itg dot com
 Reported By:  peter dot chen at itg dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: sparc-sol2.10
 PHP Version:  5.2.9
 New Comment:

I'm using sparc-solaris2.10. 

Was there a flag I needed to include for my php install to enable
glob() to work?


Previous Comments:


[2009-05-28 16:50:31] j...@php.net

Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/*));'




[2009-05-28 16:49:23] j...@php.net

Exactly what Solaris version are you on?
Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/));'




[2009-05-27 23:05:14] peter dot chen at itg dot com

My apologies, I did not read all the instructions. 

Is there a flag I needed to enable when building php?

As for the code, I mistakenly left the ';' that caused the parse error.
The code should be as follows: 

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*'));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



[2009-05-23 17:03:08] j...@php.net

You obviously didn't follow the url provided in the email. Please, do 
not Add Comment to your own report, use the Edit Submission (where

the link in the email points too. 

And now, please provide the code that actually causes the problem. That

code works fine everywhere.



[2009-05-23 10:35:41] carsten_sttgt at gmx dot de

 print_r(glob($path . '*.*';));

This line give you a parse error. Must be:
| print_r(glob($path . '*.*'));

Apart from this, the code is working for me (Win,BSD).

BTW:
 [0] = .
 [1] = ..
 [2] = authtest

With your code, this can't be part of the result from glob().

Regards,
Carsten



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/48365

-- 
Edit this bug report at http://bugs.php.net/?id=48365edit=1



#48410 [Opn-Bgs]: Using database link throws unrecognized date warning

2009-05-28 Thread sixd
 ID:   48410
 Updated by:   s...@php.net
 Reported By:  krastin dot georgiev at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Linux (ALL)
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

-

The error message is from the communication between the source and
destination databases of the DB link, so PHP OCI8 is unlikely to be the
issue.

Check the query in SQL*Plus (make sure SQL*Plus use the same Oracle
environment settings as the Apache/PHP process).

Check the ORA_NLSxx environment variables in effect for the shells
starting the DBs were correct.  See metalink.oracle.com Note 236320.1
and Note 338832.1

Before updating this bug, follow up on an Oracle-specific forum or with
Oracle Support.


Previous Comments:


[2009-05-27 23:07:05] krastin dot georgiev at gmail dot com

As sample a table named TY can be created with the following two
columns:

TY_ID   INTEGER 
TY_NM   VARCHAR2(4000)

Querying this table across a link will cause the warning.



[2009-05-27 23:00:58] krastin dot georgiev at gmail dot com

Description:

When doing a call across a database link Oracle throws a warning
immediately.

Compiled using different versions of Oracle instant client and OCI
versions.

Instant Client versions:
10.2.0.3
10.2.0.4
11.1.0.7.0

OCI versions:
1.2.5
1.3.4
1.3.5

It is important to note that using 1.2.5 on Windows (precompiled) does
NOT cause this warning. This is only a problem under Linux.

Reproduce code:
---
?php

$conn = OCILogon(user, pass, //192.168.100.15/mysid);

$sql = 'SELECT * FROM dyn_audit_...@remotedb';
$stmt = oci_parse($conn, $sql);
$res = oci_execute($stmt);

if(is_array($res)) {
while ($r = oci_fetch_assoc($res)) { 
print_r($r);
echo br;
}
}   // end if

OCILogoff($conn);

?

Expected result:

Warning: oci_execute() [function.oci-execute]: ORA-01821: date format
not recognized ORA-02063: preceding line from MUREXDM in
/home/myself/proc.php on line 7







-- 
Edit this bug report at http://bugs.php.net/?id=48410edit=1



#48365 [Opn]: glob() function returns empty array

2009-05-28 Thread peter dot chen at itg dot com
 ID:   48365
 User updated by:  peter dot chen at itg dot com
 Reported By:  peter dot chen at itg dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: sparc-sol2.10
 PHP Version:  5.2.9
 New Comment:

Oh yeah, and the command returns:

bool(false)


Previous Comments:


[2009-05-28 18:42:33] peter dot chen at itg dot com

I'm using sparc-solaris2.10. 

Was there a flag I needed to include for my php install to enable
glob() to work?



[2009-05-28 16:50:31] j...@php.net

Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/*));'




[2009-05-28 16:49:23] j...@php.net

Exactly what Solaris version are you on?
Try this on command line:

# php -r 'var_dump(glob(/home/apache/htdocs/testkt/));'




[2009-05-27 23:05:14] peter dot chen at itg dot com

My apologies, I did not read all the instructions. 

Is there a flag I needed to enable when building php?

As for the code, I mistakenly left the ';' that caused the parse error.
The code should be as follows: 

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
titleglob test/title
/head
body
?
   $path = /home/apache/htdocs/testkt/;
 
print(bglob:/bbrbr);
print_r(glob($path . '*.*'));

print(brbr***brbr);

print(bscandir:/bbrbr);
print_r(scandir($path));
?
/body
/html



[2009-05-23 17:03:08] j...@php.net

You obviously didn't follow the url provided in the email. Please, do 
not Add Comment to your own report, use the Edit Submission (where

the link in the email points too. 

And now, please provide the code that actually causes the problem. That

code works fine everywhere.



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/48365

-- 
Edit this bug report at http://bugs.php.net/?id=48365edit=1



#48418 [NEW]: NaN NaN, NaN 0, NaN 0 return true

2009-05-28 Thread phplists at stanvassilev dot com
From: phplists at stanvassilev dot com
Operating system: Linux, BSD, possibly all *nix
PHP version:  5.2.9
PHP Bug Type: Math related
Bug description:  NaN  NaN, NaN  0, NaN  0 return true

Description:

Tested on Gentoo, CentOS, OSX. 

This is possibly NOT related to the Windows NaN bug, as Windows is NOT 
affected by this issue. 

However, please test if any fix doesn't cause regression on Windows.

NaN  NaN, NaN  0, NaN  0 return true, while they should return false 
in all cases (any comparison where either side is NaN, should return 
false).

Reproduce code:
---
$NaN = sqrt(-1);
var_dump($NaN  $NaN);
var_dump($NaN  0);
var_dump($NaN  0); 

Expected result:

float(NAN)
bool(false)
bool(false)
bool(false)

Actual result:
--
float(NAN)
bool(true)
bool(true)
bool(true)

-- 
Edit bug report at http://bugs.php.net/?id=48418edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48418r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48418r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48418r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48418r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48418r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48418r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48418r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48418r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48418r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48418r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48418r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48418r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48418r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48418r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48418r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48418r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48418r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48418r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48418r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48418r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48418r=mysqlcfg



#48418 [Com]: NaN NaN, NaN 0, NaN 0 return true

2009-05-28 Thread phplists at stanvassilev dot com
 ID:   48418
 Comment by:   phplists at stanvassilev dot com
 Reported By:  phplists at stanvassilev dot com
 Status:   Open
 Bug Type: Math related
 Operating System: Linux, BSD, possibly all *nix
 PHP Version:  5.2.9
 New Comment:

And to add a note:

$NaN = $NaN
$NaN = 0
$NaN = 0

These also return true and must return false.


Previous Comments:


[2009-05-28 18:57:57] phplists at stanvassilev dot com

Description:

Tested on Gentoo, CentOS, OSX. 

This is possibly NOT related to the Windows NaN bug, as Windows is NOT

affected by this issue. 

However, please test if any fix doesn't cause regression on Windows.

NaN  NaN, NaN  0, NaN  0 return true, while they should return false

in all cases (any comparison where either side is NaN, should return 
false).

Reproduce code:
---
$NaN = sqrt(-1);
var_dump($NaN  $NaN);
var_dump($NaN  0);
var_dump($NaN  0); 

Expected result:

float(NAN)
bool(false)
bool(false)
bool(false)

Actual result:
--
float(NAN)
bool(true)
bool(true)
bool(true)





-- 
Edit this bug report at http://bugs.php.net/?id=48418edit=1



#48419 [NEW]: non-portable CGI code (Empty POST data)

2009-05-28 Thread juro at shaw dot ca
From: juro at shaw dot ca
Operating system: Windows XP
PHP version:  5.2.10RC1
PHP Bug Type: CGI related
Bug description:  non-portable CGI code (Empty POST data)

Description:

Using a generic web server with a simple CGI support (running on Windows
XP), I fail to obtain any $_POST data. However, raw post data are OK. Raw
post data is sent to the PHP-CGI.exe via redirected pipe handle. PHP-CGI
reads correctly posted raw data using stdin.

I suspect the culprit may be with the following PHP source code:

File:cgi_main.c
Routine:static int sapi_cgi_read_post(char *buffer, uint count_bytes
TSRMLS_DC)

...
tmp_read_bytes = read(0, buffer + read_bytes, count_bytes - read_bytes);
...

Low level i/o functions read,write,open are not 100% portable.
The code is most like meant to read stdin. Assuming that file descriptor
for stdin is numerically equal to 0 on all platforms is wrong. 

The code should be probably something like this
tmp_read_bytes = read(_fileno(stdin), buffer + read_bytes, count_bytes -
read_bytes);





-- 
Edit bug report at http://bugs.php.net/?id=48419edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48419r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48419r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48419r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48419r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48419r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48419r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48419r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48419r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48419r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48419r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48419r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48419r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48419r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48419r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48419r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48419r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48419r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48419r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48419r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48419r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48419r=mysqlcfg



#48416 [Fbk-Csd]: Memleak in ereg() and eregi() functions

2009-05-28 Thread scottmac
 ID:   48416
 Updated by:   scott...@php.net
 Reported By:  bmorel at ssi dot fr
-Status:   Feedback
+Status:   Closed
 Bug Type: Regexps related
 Operating System: CentOS 5.3
 PHP Version:  5.2.9
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Added a LRU and a cache limit to the ereg code for 5.3.

Give it a few hours and grab another 5.3 snapshot, not sure about
fixing this in 5.2. Will check with ilia.


Previous Comments:


[2009-05-28 18:17:49] bmorel at ssi dot fr

Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev :
php5.3-200905281630).

The cache seems to be a good explanation, but it this a good idea ?
I have millions of ereg()s done when I parse huge XML files (several
GB), and my memory usage goes too high. I had to replace all my ereg()s
with preg_match()s.

Thanks,
Ben



[2009-05-28 17:30:21] scott...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Pretty sure this is due to the regular expression cache we have, each
unique regular expression is cached so we don't keep compiling it but
there is no cap on the number we store.

Can you try a 5.3 snapshot, I think we switched from using ereg to pcre
with 5.3.



[2009-05-28 16:57:59] bmorel at ssi dot fr

Description:

When repeating an ereg() or eregi() on different patterns, the memory
usage of httpd (or php if executed from the command-line) gets huge
(about 1GB for the example below) for the time the script executes, then
the memory is freed.
During this time, the memory_get_usage() stays normal, and php's memory
limit doesn't trigger.

When repeating the ereg() with the same pattern each time, the memory
usage stays normal; this happens only when repeating with a different
pattern each time.

Verified on CentOS with PHP 5.2.6  5.2.9
Verified on Windows XP with PHP 5.2.8

Reproduce code:
---
?php
for ($i=0;$i100;$i++) ereg($i,test);
?

Expected result:

Memory usage staying low.

Actual result:
--
Memory usage as shown by top -d 1 gets huge.





-- 
Edit this bug report at http://bugs.php.net/?id=48416edit=1



#48420 [NEW]: stream_get_line() - invalid result when passing $length and $ending

2009-05-28 Thread ryan dot brothers at gmail dot com
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version:  5.2.9
PHP Bug Type: Streams related
Bug description:  stream_get_line() - invalid result when passing $length and 
$ending

Description:

When you pass to stream_get_line() a $length that is greater than the file
size and a $ending that does not appear in the file, stream_get_line()
returns bool(false) rather than the string that is in your file.

In the below example, when I run stream_get_line() passing in a $length of
6 and a $ending of \n, stream_get_line() returns false rather than the
contents of the file.

The manual states Reading ends when length bytes have been read, when the
string specified by ending is found (which is not included in the return
value), or on EOF (whichever comes first)., so I believe the contents of
my file should be returned since EOF is first to be reached.

Reproduce code:
---
?php
$fp = tmpfile();

fwrite($fp, '12345');

fseek($fp, 0);
var_dump(stream_get_line($fp, 5));

fseek($fp, 0);
var_dump(stream_get_line($fp, 6));

fseek($fp, 0);
var_dump(stream_get_line($fp, 5, \n));

fseek($fp, 0);
var_dump(stream_get_line($fp, 6, \n));

fclose($fp);


Expected result:

string(5) 12345
string(5) 12345
string(5) 12345
string(5) 12345


Actual result:
--
string(5) 12345
string(5) 12345
string(5) 12345
bool(false)


-- 
Edit bug report at http://bugs.php.net/?id=48420edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48420r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48420r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48420r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48420r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48420r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48420r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48420r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48420r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48420r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48420r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48420r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48420r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48420r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48420r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48420r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48420r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48420r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48420r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48420r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48420r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48420r=mysqlcfg



#48421 [NEW]: stream_get_line() - allow $length to be optional

2009-05-28 Thread ryan dot brothers at gmail dot com
From: ryan dot brothers at gmail dot com
Operating system: Linux
PHP version:  5.2.9
PHP Bug Type: Feature/Change Request
Bug description:  stream_get_line() - allow $length to be optional

Description:

I believe stream_get_line() should allow the $length parameter to be
optional by allowing a $length of -1 that would read the remaining buffer
up to either the $ending delimiter or EOF.

Currently if you pass a $length of 0, the $length defaults to
PHP_SOCK_CHUNK_SIZE (8192) in ext/standard/streamsfuncs.c.  If you pass a
length of -1, a PHP Warning is generated.

Other 'similar' functions that allow length to be optional or -1 are
fgets, stream_get_contents, and file_get_contents.

Also, the manual page for stream_get_line() states that this function is
the same fgets() except for the handling of the delimiter - but another
difference, at least right now, is that the $length parameter is required
in stream_get_line(), but optional in fgets().


Reproduce code:
---
?php
$fp = tmpfile();

fwrite($fp, str_repeat('a', 1));

fseek($fp, 0);
echo strlen(stream_get_line($fp, 0));

fseek($fp, 0);
echo strlen(stream_get_line($fp, -1));

fclose($fp);


Expected result:

8192
1

Actual result:
--
8192
Warning: stream_get_line(): The maximum allowed length must be greater
than or equal to zero

-- 
Edit bug report at http://bugs.php.net/?id=48421edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48421r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48421r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48421r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48421r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48421r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48421r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48421r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48421r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48421r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48421r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48421r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48421r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48421r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48421r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48421r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48421r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48421r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48421r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48421r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48421r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48421r=mysqlcfg



#48422 [NEW]: Math sum error

2009-05-28 Thread fernandokts at msn dot com
From: fernandokts at msn dot com
Operating system: Linux
PHP version:  5.2.9
PHP Bug Type: Math related
Bug description:  Math sum error

Description:

When doing simple math, there is a problem with numbers with 2 digits
greater then 07 in sums.
It appears to ignore any numbers starting with a zero that are bigger then
07.

Reproduce code:
---
?
$calc = 01 + 03 + 05 + 06 + 07 + 08;
echo The result is: $calc;
?

Expected result:

The result is: 30

Actual result:
--
The result is: 22

-- 
Edit bug report at http://bugs.php.net/?id=48422edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48422r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48422r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48422r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48422r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48422r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48422r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48422r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48422r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48422r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48422r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48422r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48422r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48422r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48422r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48422r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48422r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48422r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48422r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48422r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48422r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48422r=mysqlcfg



#48422 [Opn-Bgs]: Math sum error

2009-05-28 Thread rasmus
 ID:   48422
 Updated by:   ras...@php.net
 Reported By:  fernandokts at msn dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

You have discovered octal numbers.  Not a bug.


Previous Comments:


[2009-05-28 22:44:37] fernandokts at msn dot com

Description:

When doing simple math, there is a problem with numbers with 2 digits
greater then 07 in sums.
It appears to ignore any numbers starting with a zero that are bigger
then 07.

Reproduce code:
---
?
$calc = 01 + 03 + 05 + 06 + 07 + 08;
echo The result is: $calc;
?

Expected result:

The result is: 30

Actual result:
--
The result is: 22





-- 
Edit this bug report at http://bugs.php.net/?id=48422edit=1



#48416 [Csd]: Memleak in ereg() and eregi() functions

2009-05-28 Thread scottmac
 ID:   48416
 Updated by:   scott...@php.net
 Reported By:  bmorel at ssi dot fr
 Status:   Closed
 Bug Type: Regexps related
 Operating System: CentOS 5.3
 PHP Version:  5.2.9
 New Comment:

Fixed in 5.2 as well now.


Previous Comments:


[2009-05-28 21:58:10] scott...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Added a LRU and a cache limit to the ereg code for 5.3.

Give it a few hours and grab another 5.3 snapshot, not sure about
fixing this in 5.2. Will check with ilia.



[2009-05-28 18:17:49] bmorel at ssi dot fr

Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev :
php5.3-200905281630).

The cache seems to be a good explanation, but it this a good idea ?
I have millions of ereg()s done when I parse huge XML files (several
GB), and my memory usage goes too high. I had to replace all my ereg()s
with preg_match()s.

Thanks,
Ben



[2009-05-28 17:30:21] scott...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Pretty sure this is due to the regular expression cache we have, each
unique regular expression is cached so we don't keep compiling it but
there is no cap on the number we store.

Can you try a 5.3 snapshot, I think we switched from using ereg to pcre
with 5.3.



[2009-05-28 16:57:59] bmorel at ssi dot fr

Description:

When repeating an ereg() or eregi() on different patterns, the memory
usage of httpd (or php if executed from the command-line) gets huge
(about 1GB for the example below) for the time the script executes, then
the memory is freed.
During this time, the memory_get_usage() stays normal, and php's memory
limit doesn't trigger.

When repeating the ereg() with the same pattern each time, the memory
usage stays normal; this happens only when repeating with a different
pattern each time.

Verified on CentOS with PHP 5.2.6  5.2.9
Verified on Windows XP with PHP 5.2.8

Reproduce code:
---
?php
for ($i=0;$i100;$i++) ereg($i,test);
?

Expected result:

Memory usage staying low.

Actual result:
--
Memory usage as shown by top -d 1 gets huge.





-- 
Edit this bug report at http://bugs.php.net/?id=48416edit=1



#48423 [NEW]: ksort applied with array_walk not working consistently

2009-05-28 Thread brad at njoe dot com
From: brad at njoe dot com
Operating system: Windows  *nix
PHP version:  5.2.9
PHP Bug Type: Arrays related
Bug description:  ksort applied with array_walk not working consistently

Description:

While using array_walk() to apply ksort() to a multidimensional array, I
experienced some unusual results. I expected that since each sub-array
contained identical keys and values that they would all be sorted in the
same manner. See the example code/expected output below for more
information.

I've tried this on Windows (ver. 5.2.9-2) as well as a Linux box (ver.
5.2.6) and both yielded the same results. If I manually walk ksort()
through the array, i.e.:
ksort($test[0]);
ksort($test[1]);
ksort($test[2]);
ksort($test[3]);
ksort($test[4]);
ksort($test[5]);
then the results are as expected. I've tried with varying number of array
elements in the parent array as well as changing the keys around; no matter
what I did, the array in $test[1] was always sorted incorrectly (and
unpredictably at that).

Reproduce code:
---
?php
$test = array(
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6')
);

array_walk($test, 'ksort');

print_r($test);
?

Expected result:

Array
(
[0] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[1] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[2] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[3] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[4] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[5] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

)

Actual result:
--
Array
(
[0] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[1] = Array
(
[foo] = value5
[bar] = value6
[blah] = value4
[word] = value3
[this] = value2
[key] = value1
)

[2] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[3] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[4] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

[5] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)

)

-- 
Edit bug report at http://bugs.php.net/?id=48423edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48423r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48423r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48423r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48423r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48423r=needdocs
Fixed in release:

#48424 [NEW]: strtotime changes year to current year with date formatted 17 July, 2004

2009-05-28 Thread php at qrs dot oib dot com
From: php at qrs dot oib dot com
Operating system: Windows XP, Linux
PHP version:  5.2.9
PHP Bug Type: Date/time related
Bug description:  strtotime changes year to current year with date formatted 
17 July, 2004

Description:

strtotime changes the year to the current year with a date formatted like
17 July, 2004.

Reproduce code:
---
print strftime(%d %B, %Y, strtotime(July 17, 2004));
print strftime(%d %B, %Y, strtotime(17 July, 2004)); // ---
print strftime(%d %B, %Y, strtotime(17 July 2004));

Expected result:

17 July, 2004
17 July, 2004
17 July, 2004

Actual result:
--
17 July, 2004
17 July, 2009
17 July, 2004

-- 
Edit bug report at http://bugs.php.net/?id=48424edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48424r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48424r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48424r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48424r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48424r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48424r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48424r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48424r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48424r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48424r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48424r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48424r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48424r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48424r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48424r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48424r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48424r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48424r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48424r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48424r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48424r=mysqlcfg



#48425 [NEW]: Can not call static methods from .net DLL

2009-05-28 Thread halflife at cableone dot net
From: halflife at cableone dot net
Operating system: Windows Server 2003
PHP version:  5.2.9
PHP Bug Type: COM related
Bug description:  Can not call static methods from .net DLL

Description:

I can call any public methods in a public class from my dll no 
problem, but calling any methods that are set as static, results in 
the error

Fatal error: Call to undefined method com::DoMD5() in 
C:\wamp\www\xxx\netphp.php on line 5





Reproduce code:
---
Source to dll class a href=http://www.dlgnetworks.com/HashPotato.cs

PHP Code calling it

$DLGtb = new COM(DLG.Crypto.HashPotato);
echo $DLGtb-DoMD5(test);


Expected result:

Should return the MD5 of the string

Actual result:
--
Fatal error: Call to undefined method com::DoMD5()

-- 
Edit bug report at http://bugs.php.net/?id=48425edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48425r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48425r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48425r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48425r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48425r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48425r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48425r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48425r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48425r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48425r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48425r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48425r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48425r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48425r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48425r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48425r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48425r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48425r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48425r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48425r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48425r=mysqlcfg