Bug #62852 [Com]: Unserialize Invalid Date causes crash

[reeze dot xia at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62852edit=1

 ID: 62852
 Comment by: reeze dot xia at gmail dot com
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Hi, 
   I'v sent pull request to fix this:
https://github.com/php/php-src/pull/168

when unserialize it didn't check whether the date is valid.

Thanks


Previous Comments:

[2012-08-18 11:53:03] kasper at webmasteren dot eu

Description:

Core PHP,every version so far, 5.3.* and 5.4.*
When unserializing this string :
O:8:DateTime:3:{s:4:date;s:20:10007-06-07 
03:51:49;s:13:timezone_type;i:3;s:8:timezone;s:3:UTC;}
created from: Datetime:createFromFormat(99-99-,j-n-Y);
then serialized, to a file. Later when read and working with, php crashes, from 
the parse_tz.c, in timelib_get_time_zone_info. the Exception is read at offset 
0x0010. it would appear that ts and / or tz is zero. 


Test script:
---
$temp =  unserialize('O:8:DateTime:3:{s:4:date;s:20:10007-06-07 
03:51:49;s:13:timezone_type;i:3;s:8:timezone;s:3:UTC;}');
var_dump($temp);

Expected result:

error parsing invalid date or just a date with all entries 0.

Actual result:
--
php crash [read offset 0x0010] ~  null pointer + offset. at the file 
ext\date\lib\parse_tz.c






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

[PHP-BUG] Req #62864 [NEW]: strftime(%A) with locale set to french outputs date with capital letter

[pierrelouis dot peeters at gmail dot com]

From: pierrelouis dot peeters at gmail dot com
Operating system: Unix
PHP version:  5.4Git-2012-08-19 (snap)
Package:  Date/time related
Bug Type: Feature/Change Request
Bug description:strftime(%A) with locale set to french outputs date with 
capital letter

Description:

If you put locale to French (fr_FR), strftime outputs the day with a
capital 
letter instead of all lowercase (e.g.: it outputs 'Vendredi' instead of 
'vendredi'). In French, days don't have capital letters.

Test script:
---
setlocale(LC_ALL, 'fr_FR');
echo strftime(%A);

Expected result:

The current day in lowercase.

Actual result:
--
The current day with a capital letter.

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

Bug #62771 [Com]: Compiling with Imap-2007f is failed

[gencer at cmail dot cm]

Edit report at https://bugs.php.net/bug.php?id=62771edit=1

 ID: 62771
 Comment by: gencer at cmail dot cm
 Reported by:gencer at cmail dot cm
 Summary:Compiling with Imap-2007f is failed
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   CentOS 6.3
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Hi,

Issue resolved. It seems PHP 5.4.6 has this fix. I am able to install with IMAP 
feature successfully.

Gencer.


Previous Comments:

[2012-08-07 17:51:31] gencer at cmail dot cm

Description:

When i try to compile with IMAP, it just thrown an error and say

error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This 
should not happen. Check config.log for additional information.

I am trying to use imap-2007f from source. I did make on imap-2007f before 
compiling PHP and imap relays on /usr/local/imap-2007f

I also tried imap-2007e.

And yes, libc-client and libc-client-devel is installed by RPM. But the version 
is 2007e. As i said both 2007e and 2007f gives the same exact error.

Here is the config.log - http://www.mediafire.com/?1qpg27j7xd19l6o

I built PHP many times with the exact this configure parameters before. All of 
them on CentOS 5.8. I am getting this error on 6.3. Weird. Same parameters with 
centos 5.8 did the job.

Most weird thing is; If i only use --with-imap (without path) it gives me the 
same error.

Test script:
---
'./configure' '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' 
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' 
'--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--cache-file=../config.cache' 
'--with-libdir=lib64' '--with-config-file-path=/etc' 
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' 
'--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' 
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' 
'--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' 
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' 
'--with-pcre-regex' '--with-zlib' '--with-layout=GNU' '--enable-exif' 
'--enable-ftp' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' 
'--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-libxml' 
'--with-xmlrpc' '--enable-xml' '--with-system-tzdata' '--with-mhash' 
'--with-mysql' '--with-gd' '--enable-dom' '--disable-dba' 
'--without-unixODBC--disable-xmlreader' '--disable-xmlwriter' 
'--without-sqlite' '--with-sqlite3' '--enable-phar' '--enable-fileinfo' 
'--enable-json' '--without-pspell' '--disable-wddx' '--disable-posix' 
'--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' '--enable-pdo' 
'--enable-mbstring' '--enable-fastcgi' '--with-mcrypt' '--enable-fpm' 
'--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-pcntl' 
'--with-imap=../imap-2007f' '--with-imap-ssl' '--with-pgsql=/usr/pgsql-9.2' 
'--with-pdo-pgsql=/usr/pgsql-9.2' '--with-curl=../curl-7.26.0'

Expected result:

PHP compiles as it did before on CentOS 5.8.

Actual result:
--
checking if your cpp allows macro usage in include lines... yes
checking for IMAP support... yes
checking for IMAP Kerberos support... yes
checking for IMAP SSL support... yes
checking for utf8_mime2text signature... (cached) old
checking for U8T_DECOMPOSE...
configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL is 
present. This should not happen. Check config.log for additional information.







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

Bug #62852 [Opn-Csd]: Unserialize Invalid Date causes crash

[laruence]

Edit report at https://bugs.php.net/bug.php?id=62852edit=1

 ID: 62852
 Updated by: larue...@php.net
 Reported by:kasper at webmasteren dot eu
 Summary:Unserialize Invalid Date causes crash
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   windows, linux
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-08-19 10:32:23] larue...@php.net

Automatic comment on behalf of reeze@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=46a3f257724df7b85cc8c3e6374c36ed9ee783b4
Log: Fixed bug #62852 (Unserialize invalid DateTime causes crash)


[2012-08-19 10:31:21] larue...@php.net

Automatic comment on behalf of reeze@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=46a3f257724df7b85cc8c3e6374c36ed9ee783b4
Log: Fixed bug #62852 (Unserialize invalid DateTime causes crash)


[2012-08-19 10:30:36] larue...@php.net

Automatic comment on behalf of reeze@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=46a3f257724df7b85cc8c3e6374c36ed9ee783b4
Log: Fixed bug #62852 (Unserialize invalid DateTime causes crash)


[2012-08-19 08:08:17] reeze dot xia at gmail dot com

Hi, 
   I'v sent pull request to fix this:
https://github.com/php/php-src/pull/168

when unserialize it didn't check whether the date is valid.

Thanks


[2012-08-18 11:53:03] kasper at webmasteren dot eu

Description:

Core PHP,every version so far, 5.3.* and 5.4.*
When unserializing this string :
O:8:DateTime:3:{s:4:date;s:20:10007-06-07 
03:51:49;s:13:timezone_type;i:3;s:8:timezone;s:3:UTC;}
created from: Datetime:createFromFormat(99-99-,j-n-Y);
then serialized, to a file. Later when read and working with, php crashes, from 
the parse_tz.c, in timelib_get_time_zone_info. the Exception is read at offset 
0x0010. it would appear that ts and / or tz is zero. 


Test script:
---
$temp =  unserialize('O:8:DateTime:3:{s:4:date;s:20:10007-06-07 
03:51:49;s:13:timezone_type;i:3;s:8:timezone;s:3:UTC;}');
var_dump($temp);

Expected result:

error parsing invalid date or just a date with all entries 0.

Actual result:
--
php crash [read offset 0x0010] ~  null pointer + offset. at the file 
ext\date\lib\parse_tz.c






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

[PHP-BUG] Bug #62865 [NEW]: Page along with AJAX postback is working on Apache not in IIS

[akshay dot srin at gmail dot com]

From: akshay dot srin at gmail dot com
Operating system: Windows 7
PHP version:  5.4.6
Package:  IIS related
Bug Type: Bug
Bug description:Page along with AJAX postback is working on Apache not in IIS

Description:

The URL on which IIS is server up same PHP page is 
http://114.143.28.50/phpexample1/default.php.  If you click the button
which 
says Custom Click Function it does a postback to a PHP page which returns
data 
but in the case of IIS doesnt.

The working Apache page is at 
http://114.143.28.50:8080/phpexample1/public/default.php.  Here when you
click 
the button an alert and the label is changed to did postback and all the 
controls are in working order.

This is an invention of mine so it is new you can download the source from

https://github.com/akshaysrin/CanvasControlLibrary.

For some documentation on how it works I maintain a rather large article on

CodeProject here is the link
http://www.codeproject.com/Articles/410856/Canvas-
Control-Library-and-New-Forms-Based-System.

Test script:
---
You will have to check out the source code which is freely downloadable.

Expected result:

Alert message and label changes to Did Postback

Actual result:
--
Nothing no change AJAX postback returns with no result only on IIS PHP.

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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[soapergem at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 User updated by:soapergem at gmail dot com
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?


Previous Comments:

[2012-08-19 05:22:03] ras...@php.net

I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows 
internally is actually UTF-16 but there is a library call named isTextUnicode() 
which most apps use to determine which encoding something is in and it tends 
towards CP-1252 if it can't figure it out, so I assume that is what you mean 
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I 
know 
of has a very simple encoding setting to force the editor to a specific 
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-
1252 is not used in most of the world, so this assertion that most pages are 
saved in ISO-8859-1 is obviously not true. Regardless, this is not something 
that will be reverted. CP-1252 is disappearing and I think you will find much 
less of it in Windows8 as it really doesn't play well with HTML5.


[2012-08-19 05:02:02] soapergem at gmail dot com

With respect, the 72% figure you cited is misleading at best. The character 
encoding listed in the HTML gives no indication of what encoding the files were 
actually saved in. All it is is a meta tag in that head that says UTF-8. I 
would suspect the vast majority of those files are still saved in ISO-8859-1, 
though.

My prediction is that you're going to get A LOT of complaints over the switch 
-- 
especially from Windows users, who almost always save things in ISO-8859-1, 
since that is the default encoding in Windows. With PHP on Windows ever 
growing, 
fighting the Windows users is just shooting yourself in the foot.


[2012-08-19 04:38:50] ras...@php.net

UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in 
ISO-8859-1 is character code (in hex) A9. In UTF-8 the copyright symbol is 
represented by two bytes, C2A9. The world has gone UTF-8. If your editor is 
in UTF-8 mode and you enter/paste a copyright symbol and pass it to 
htmlentities() you will get copy; back. So rather than change the code to 
hardcode ISO-8859-1 you should convert your datasources to UTF-8. Most of them 
are probably already UTF-8 which means that your current code was likely not 
handling these correctly since it assumed ISO-8859-1 before.

For some perspetive: 
http://w3techs.com/technologies/overview/character_encoding/all
which shows that 72% of the top-million sites on the Web are using UTF-8. And 
this number is growing.


[2012-08-19 04:14:03] soapergem at gmail dot com

Description:

Doesn't UTF-8 include basic ASCII characters, too? Right now when I try to 
encode the copyright symbol (©) using htmlentities (it should encode to 

Bug #62865 [Opn-Csd]: Page along with AJAX postback is working on Apache not in IIS

[akshay dot srin at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62865edit=1

 ID: 62865
 User updated by:akshay dot srin at gmail dot com
 Reported by:akshay dot srin at gmail dot com
 Summary:Page along with AJAX postback is working on Apache
 not in IIS
-Status: Open
+Status: Closed
 Type:   Bug
 Package:IIS related
 Operating System:   Windows 7
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

It does not allow AJAX calls cross sites and web servers.


Previous Comments:

[2012-08-19 11:37:01] akshay dot srin at gmail dot com

Description:

The URL on which IIS is server up same PHP page is 
http://114.143.28.50/phpexample1/default.php.  If you click the button which 
says Custom Click Function it does a postback to a PHP page which returns data 
but in the case of IIS doesnt.

The working Apache page is at 
http://114.143.28.50:8080/phpexample1/public/default.php.  Here when you click 
the button an alert and the label is changed to did postback and all the 
controls are in working order.

This is an invention of mine so it is new you can download the source from 
https://github.com/akshaysrin/CanvasControlLibrary.

For some documentation on how it works I maintain a rather large article on 
CodeProject here is the link http://www.codeproject.com/Articles/410856/Canvas-
Control-Library-and-New-Forms-Based-System.

Test script:
---
You will have to check out the source code which is freely downloadable.

Expected result:

Alert message and label changes to Did Postback

Actual result:
--
Nothing no change AJAX postback returns with no result only on IIS PHP.






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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 Updated by: ras...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.


Previous Comments:

[2012-08-19 13:30:07] soapergem at gmail dot com

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?


[2012-08-19 05:22:03] ras...@php.net

I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows 
internally is actually UTF-16 but there is a library call named isTextUnicode() 
which most apps use to determine which encoding something is in and it tends 
towards CP-1252 if it can't figure it out, so I assume that is what you mean 
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I 
know 
of has a very simple encoding setting to force the editor to a specific 
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-
1252 is not used in most of the world, so this assertion that most pages are 
saved in ISO-8859-1 is obviously not true. Regardless, this is not something 
that will be reverted. CP-1252 is disappearing and I think you will find much 
less of it in Windows8 as it really doesn't play well with HTML5.


[2012-08-19 05:02:02] soapergem at gmail dot com

With respect, the 72% figure you cited is misleading at best. The character 
encoding listed in the HTML gives no indication of what encoding the files were 
actually saved in. All it is is a meta tag in that head that says UTF-8. I 
would suspect the vast majority of those files are still saved in ISO-8859-1, 
though.

My prediction is that you're going to get A LOT of complaints over the switch 
-- 
especially from Windows users, who almost always save things in ISO-8859-1, 
since that is the default encoding in Windows. With PHP on Windows ever 
growing, 
fighting the Windows users is just shooting yourself in the foot.


[2012-08-19 04:38:50] ras...@php.net

UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in 
ISO-8859-1 is character code (in hex) A9. In UTF-8 the copyright symbol is 
represented by two bytes, C2A9. The world has gone UTF-8. If your editor is 
in UTF-8 mode and you enter/paste a copyright symbol and pass it to 
htmlentities() you will get copy; back. So rather than change the code to 
hardcode ISO-8859-1 you should convert your datasources to 

Bug #62865 [Csd-Nab]: Page along with AJAX postback is working on Apache not in IIS

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=62865edit=1

 ID: 62865
 Updated by: ras...@php.net
 Reported by:akshay dot srin at gmail dot com
 Summary:Page along with AJAX postback is working on Apache
 not in IIS
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:IIS related
 Operating System:   Windows 7
 PHP Version:5.4.6
 Block user comment: N
 Private report: N



Previous Comments:

[2012-08-19 13:40:38] akshay dot srin at gmail dot com

It does not allow AJAX calls cross sites and web servers.


[2012-08-19 11:37:01] akshay dot srin at gmail dot com

Description:

The URL on which IIS is server up same PHP page is 
http://114.143.28.50/phpexample1/default.php.  If you click the button which 
says Custom Click Function it does a postback to a PHP page which returns data 
but in the case of IIS doesnt.

The working Apache page is at 
http://114.143.28.50:8080/phpexample1/public/default.php.  Here when you click 
the button an alert and the label is changed to did postback and all the 
controls are in working order.

This is an invention of mine so it is new you can download the source from 
https://github.com/akshaysrin/CanvasControlLibrary.

For some documentation on how it works I maintain a rather large article on 
CodeProject here is the link http://www.codeproject.com/Articles/410856/Canvas-
Control-Library-and-New-Forms-Based-System.

Test script:
---
You will have to check out the source code which is freely downloadable.

Expected result:

Alert message and label changes to Did Postback

Actual result:
--
Nothing no change AJAX postback returns with no result only on IIS PHP.






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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[nikic]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 Updated by: ni...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).


Previous Comments:

[2012-08-19 13:49:39] ras...@php.net

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.


[2012-08-19 13:30:07] soapergem at gmail dot com

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?


[2012-08-19 05:22:03] ras...@php.net

I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows 
internally is actually UTF-16 but there is a library call named isTextUnicode() 
which most apps use to determine which encoding something is in and it tends 
towards CP-1252 if it can't figure it out, so I assume that is what you mean 
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I 
know 
of has a very simple encoding setting to force the editor to a specific 
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-
1252 is not used in most of the world, so this assertion that most pages are 
saved in ISO-8859-1 is obviously not true. Regardless, this is not something 
that will be reverted. CP-1252 is disappearing and I think you will find much 
less of it in Windows8 as it really doesn't play well with HTML5.


[2012-08-19 05:02:02] soapergem at gmail dot com

With respect, the 72% figure you cited is misleading at best. The character 
encoding listed in the HTML gives no indication of what encoding the files were 
actually saved in. All it is is a meta tag in that head that says UTF-8. I 
would suspect the vast majority of those files are still saved in ISO-8859-1, 
though.

My prediction is that you're going to get A LOT of complaints over the switch 
-- 
especially from Windows users, who almost always save things in ISO-8859-1, 
since that is the default encoding in Windows. With PHP on Windows ever 
growing, 
fighting the Windows users is just shooting yourself in the foot.


[2012-08-19 04:38:50] ras...@php.net

UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in 
ISO-8859-1 is character code (in hex) 

Bug #62771 [Opn-Csd]: Compiling with Imap-2007f is failed

[nikic]

Edit report at https://bugs.php.net/bug.php?id=62771edit=1

 ID: 62771
 Updated by: ni...@php.net
 Reported by:gencer at cmail dot cm
 Summary:Compiling with Imap-2007f is failed
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   CentOS 6.3
 PHP Version:5.4.5
-Assigned To:
+Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

Closing this bug report as the issue is resolved :)


Previous Comments:

[2012-08-19 10:24:50] gencer at cmail dot cm

Hi,

Issue resolved. It seems PHP 5.4.6 has this fix. I am able to install with IMAP 
feature successfully.

Gencer.


[2012-08-07 17:51:31] gencer at cmail dot cm

Description:

When i try to compile with IMAP, it just thrown an error and say

error: utf8_mime2text() has old signature, but U8T_CANONICAL is present. This 
should not happen. Check config.log for additional information.

I am trying to use imap-2007f from source. I did make on imap-2007f before 
compiling PHP and imap relays on /usr/local/imap-2007f

I also tried imap-2007e.

And yes, libc-client and libc-client-devel is installed by RPM. But the version 
is 2007e. As i said both 2007e and 2007f gives the same exact error.

Here is the config.log - http://www.mediafire.com/?1qpg27j7xd19l6o

I built PHP many times with the exact this configure parameters before. All of 
them on CentOS 5.8. I am getting this error on 6.3. Weird. Same parameters with 
centos 5.8 did the job.

Most weird thing is; If i only use --with-imap (without path) it gives me the 
same error.

Test script:
---
'./configure' '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' 
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' 
'--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--cache-file=../config.cache' 
'--with-libdir=lib64' '--with-config-file-path=/etc' 
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' 
'--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' 
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' 
'--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' 
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' 
'--with-pcre-regex' '--with-zlib' '--with-layout=GNU' '--enable-exif' 
'--enable-ftp' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' 
'--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-libxml' 
'--with-xmlrpc' '--enable-xml' '--with-system-tzdata' '--with-mhash' 
'--with-mysql' '--with-gd' '--enable-dom' '--disable-dba' 
'--without-unixODBC--disable-xmlreader' '--disable-xmlwriter' 
'--without-sqlite' '--with-sqlite3' '--enable-phar' '--enable-fileinfo' 
'--enable-json' '--without-pspell' '--disable-wddx' '--disable-posix' 
'--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' '--enable-pdo' 
'--enable-mbstring' '--enable-fastcgi' '--with-mcrypt' '--enable-fpm' 
'--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--enable-pcntl' 
'--with-imap=../imap-2007f' '--with-imap-ssl' '--with-pgsql=/usr/pgsql-9.2' 
'--with-pdo-pgsql=/usr/pgsql-9.2' '--with-curl=../curl-7.26.0'

Expected result:

PHP compiles as it did before on CentOS 5.8.

Actual result:
--
checking if your cpp allows macro usage in include lines... yes
checking for IMAP support... yes
checking for IMAP Kerberos support... yes
checking for IMAP SSL support... yes
checking for utf8_mime2text signature... (cached) old
checking for U8T_DECOMPOSE...
configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL is 
present. This should not happen. Check config.log for additional information.







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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[soapergem at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 User updated by:soapergem at gmail dot com
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.


Previous Comments:

[2012-08-19 13:59:09] ni...@php.net

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).


[2012-08-19 13:49:39] ras...@php.net

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.


[2012-08-19 13:30:07] soapergem at gmail dot com

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?


[2012-08-19 05:22:03] ras...@php.net

I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows 
internally is actually UTF-16 but there is a library call named isTextUnicode() 
which most apps use to determine which encoding something is in and it tends 
towards CP-1252 if it can't figure it out, so I assume that is what you mean 
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I 
know 
of has a very simple encoding setting to force the editor to a specific 
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-
1252 is not used in most of the world, so this assertion that most pages are 
saved in ISO-8859-1 is obviously not true. Regardless, this is not something 
that will be reverted. CP-1252 is disappearing and I think you will find much 
less of it in Windows8 as it really doesn't play well with HTML5.


[2012-08-19 05:02:02] 

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[nikic]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 Updated by: ni...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Windows Notepad does not support this because Notepad is not a suitable editor 
for development. All development-oriented texteditors and IDEs support saving 
files without BOM.

One commonly used text editor for Windows is Notepad++ (in case you don't want 
to use a full-blown IDE).


Previous Comments:

[2012-08-19 14:11:43] soapergem at gmail dot com

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.


[2012-08-19 13:59:09] ni...@php.net

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).


[2012-08-19 13:49:39] ras...@php.net

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.


[2012-08-19 13:30:07] soapergem at gmail dot com

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?


[2012-08-19 05:22:03] ras...@php.net

I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows 
internally is actually UTF-16 but there is a library call named isTextUnicode() 
which most apps use to determine which encoding something is in and it tends 
towards CP-1252 if it can't figure it out, so I assume that is what you mean 
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I 
know 
of has a very simple encoding setting to force the editor to a specific 
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[rasmus]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 Updated by: ras...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Every real editor can do that. Windows Notepad is not a real editor. Notepad++ 
(which is free and much much better than Notepad), Notepad2, Textmate, Vim, 
Jedit, Ultraedit, Emacs, SourceEdit can all do this.


Previous Comments:

[2012-08-19 14:27:07] ni...@php.net

Windows Notepad does not support this because Notepad is not a suitable editor 
for development. All development-oriented texteditors and IDEs support saving 
files without BOM.

One commonly used text editor for Windows is Notepad++ (in case you don't want 
to use a full-blown IDE).


[2012-08-19 14:11:43] soapergem at gmail dot com

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.


[2012-08-19 13:59:09] ni...@php.net

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).


[2012-08-19 13:49:39] ras...@php.net

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.


[2012-08-19 13:30:07] soapergem at gmail dot com

Yes, your assumptions about what I was meaning to say were correct. I really 
meant ANSI, which you know as CP-1252.

But there is definitely still a bug with this. I just followed your 
instructions 
by saving my test script specifically in the UTF-8 encoding hoping that, as 
you said, all my problems will go away.

They didn't.

My test script is exactly the same one that I have listed on this bug report. I 
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting 
an empty string -- which is progress. But now I am getting the following output:

copy;

This is definitely NOT the expected result here. It did finally convert the 
copyright symbol, but it prepended not one, not two, but THREE junk characters 
in front of it. This is even worse than before.

If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the 
idea 
of converting everything to Unicode deemed too ambitious? I've already spent 
far 
too much time dealing with this than is practical, as I'm sure you have much 
better things to do, as well. It just seems to me that you guys had a wonderful 
hammer -- a wonderful tool for the job -- and you went and broke off the hammer 
head for no apparent reason.

If I might make a humble suggestion, why not let htmlentities() default to 
whatever the default_charset option is in php.ini? Right now you can only do 
that by explicitly passing an empty string as the third parameter to 
htmlentities, which is very messy and counterintuitive. Shouldn't the 
default_charset actually be, you know, the _default character set_?




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

https://bugs.php.net/bug.php?id=62861


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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[soapergem at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 User updated by:soapergem at gmail dot com
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

I am aware that Notepad is not a suitable editor for development. It is just 
the 
de facto basic editor in Windows. If something doesn't work in Notepad, 
you're 
usually in trouble.

I use an editor called EditPlus, which is a very good editor. The older version 
which I have used does not have support for removing the BOM, but I see the 
newer version does, so I will have to upgrade.

But I would really appreciate it if you could address my suggestion about using 
the default_charset defined in php.ini automatically. Right now having to call 
htmlentities($string, ENT_COMPAT | ENT_HTML401, ) seems very 
counter-intuitive 
to invoke what should be the default.


Previous Comments:

[2012-08-19 14:27:31] ras...@php.net

Every real editor can do that. Windows Notepad is not a real editor. Notepad++ 
(which is free and much much better than Notepad), Notepad2, Textmate, Vim, 
Jedit, Ultraedit, Emacs, SourceEdit can all do this.


[2012-08-19 14:27:07] ni...@php.net

Windows Notepad does not support this because Notepad is not a suitable editor 
for development. All development-oriented texteditors and IDEs support saving 
files without BOM.

One commonly used text editor for Windows is Notepad++ (in case you don't want 
to use a full-blown IDE).


[2012-08-19 14:11:43] soapergem at gmail dot com

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.


[2012-08-19 13:59:09] ni...@php.net

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).


[2012-08-19 13:49:39] ras...@php.net

From my command line:

php  echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

it works fine. If you are actually providing the correct UTF-8 char it will 
work 
fine. You can verify that by doing this:

php  $a = chr(0xC2).chr(0xA9);
php  echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;

Here I am explicitly passing C2A9 in and I get copy; back out.

So I have no idea what your Windows Notepad is doing. Look at the output with a 
hex editor and see what it is converting that copyright character to.




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

https://bugs.php.net/bug.php?id=62861


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

Bug #62861 [Com]: htmlentities returns empty string when it shouldn't

[ni...@php.net]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 Comment by: ni...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

The default_charset sets default charset for the Content-Type header. It 
doesn't really have anything to do with the htmlspecialchars() family of 
functions.

The '' encoding is some sort of magic charset detection algorithm that may or 
may not guess correctly. The docs explicitly state that you should not use it.


Previous Comments:

[2012-08-19 14:31:20] soapergem at gmail dot com

I am aware that Notepad is not a suitable editor for development. It is just 
the 
de facto basic editor in Windows. If something doesn't work in Notepad, 
you're 
usually in trouble.

I use an editor called EditPlus, which is a very good editor. The older version 
which I have used does not have support for removing the BOM, but I see the 
newer version does, so I will have to upgrade.

But I would really appreciate it if you could address my suggestion about using 
the default_charset defined in php.ini automatically. Right now having to call 
htmlentities($string, ENT_COMPAT | ENT_HTML401, ) seems very 
counter-intuitive 
to invoke what should be the default.


[2012-08-19 14:27:31] ras...@php.net

Every real editor can do that. Windows Notepad is not a real editor. Notepad++ 
(which is free and much much better than Notepad), Notepad2, Textmate, Vim, 
Jedit, Ultraedit, Emacs, SourceEdit can all do this.


[2012-08-19 14:27:07] ni...@php.net

Windows Notepad does not support this because Notepad is not a suitable editor 
for development. All development-oriented texteditors and IDEs support saving 
files without BOM.

One commonly used text editor for Windows is Notepad++ (in case you don't want 
to use a full-blown IDE).


[2012-08-19 14:11:43] soapergem at gmail dot com

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.


[2012-08-19 13:59:09] ni...@php.net

Save your document as UTF-8 *without* BOM. The  is just what the UTF-8 
Byte Order Mark (BOM) looks like when it is output (which is probably something 
you don't want, so save the file without it).




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

https://bugs.php.net/bug.php?id=62861


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

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

[soapergem at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=62861edit=1

 ID: 62861
 User updated by:soapergem at gmail dot com
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

That makes sense.

In that case, could I submit a feature request to add a config option to 
php.ini 
called default_encoding? By default (or if omitted) it would be UTF-8, of 
course. This would allow users to change it one place (or change it via 
ini_set) 
to set the default for the htmlspecialchars family of functions, rather than 
having to grep all the code to change each function call.


Previous Comments:

[2012-08-19 14:57:05] ni...@php.net

The default_charset sets default charset for the Content-Type header. It 
doesn't really have anything to do with the htmlspecialchars() family of 
functions.

The '' encoding is some sort of magic charset detection algorithm that may or 
may not guess correctly. The docs explicitly state that you should not use it.


[2012-08-19 14:31:20] soapergem at gmail dot com

I am aware that Notepad is not a suitable editor for development. It is just 
the 
de facto basic editor in Windows. If something doesn't work in Notepad, 
you're 
usually in trouble.

I use an editor called EditPlus, which is a very good editor. The older version 
which I have used does not have support for removing the BOM, but I see the 
newer version does, so I will have to upgrade.

But I would really appreciate it if you could address my suggestion about using 
the default_charset defined in php.ini automatically. Right now having to call 
htmlentities($string, ENT_COMPAT | ENT_HTML401, ) seems very 
counter-intuitive 
to invoke what should be the default.


[2012-08-19 14:27:31] ras...@php.net

Every real editor can do that. Windows Notepad is not a real editor. Notepad++ 
(which is free and much much better than Notepad), Notepad2, Textmate, Vim, 
Jedit, Ultraedit, Emacs, SourceEdit can all do this.


[2012-08-19 14:27:07] ni...@php.net

Windows Notepad does not support this because Notepad is not a suitable editor 
for development. All development-oriented texteditors and IDEs support saving 
files without BOM.

One commonly used text editor for Windows is Notepad++ (in case you don't want 
to use a full-blown IDE).


[2012-08-19 14:11:43] soapergem at gmail dot com

There is no option to save without the BOM in Windows Notepad. Nor is there an 
option to save with/without the BOM in many other Windows editors. It is 
automatically added to the file and there is nothing I can do about that -- 
short of writing a script to programmatically go through all my other scripts 
with fopen(), remove the first three characters, and then re-save.

That is NOT a practical option. PHP should be handling this.

As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need 
to 
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts 
of ANYONE who uses htmlentities() on a Windows server. Please take my 
suggestion 
about using the default_charset to heart. That would finally resolve this issue.




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

https://bugs.php.net/bug.php?id=62861


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

Bug #62844 [Com]: parse_url() does not recognize //

[ajf at ajf dot me]

Edit report at https://bugs.php.net/bug.php?id=62844edit=1

 ID: 62844
 Comment by: ajf at ajf dot me
 Reported by:phpqa at sebastianmendel dot de
 Summary:parse_url() does not recognize //
 Status: Open
 Type:   Bug
 Package:URL related
 Operating System:   Linux
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Added patch and made pull request: https://github.com/php/php-src/pull/169


Previous Comments:

[2012-08-17 09:59:15] phpqa at sebastianmendel dot de

even if doc says This function doesn't work with relative URLs. it also says: 
Partial URLs are also accepted, parse_url() tries its best to parse them 
correctly.

and it parses relative URLs like /path/file.html?var=1foo=bar#123 correctly


[2012-08-17 09:22:03] phpqa at sebastianmendel dot de

Description:

parse_url() does not recognize '//' as scheme to host separator and therefor 
does 
not recognize exemple.org as host in URL //example.org

Test script:
---
var_dump(parse_url('//example.org'));


Expected result:

array(1) {
  'host' =
  string(11) example.org
}


Actual result:
--
array(1) {
  'path' =
  string(14) //example.org
}








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

Bug #62854 [Nab-Opn]: Segfault on call_user_func_array

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=62854edit=1

 ID: 62854
 Updated by: ahar...@php.net
 Reported by:popsul1993 at gmail dot com
 Summary:Segfault on call_user_func_array
-Status: Not a bug
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

I think Felipe thought you were talking about the whole bug in the first 
comment, not just that paragraph. Reopened.


Previous Comments:

[2012-08-18 15:53:24] popsul1993 at gmail dot com

Why that not a bug? Interpreter crashes when recursion is over 
call_user_func_array, and necessary make Fatal Error. IF that code running 
under 
php 5.3 - behavior is correct, and under 5.4 - interpreter crash with segfault.

p.s. Sorry for my English.


[2012-08-18 15:13:21] fel...@php.net

.


[2012-08-18 14:21:34] popsul1993 at gmail dot com

 Also, PHP =5.4.5 have a crazy behavior, i.e. my implementation of 
ActiveRecord 
 have method 'buildSql' (with public visibility), but when run e.g. $this-
buildSql();
 that call send to __call(), where there is a checing with code 
 method_exists($this, $method_name), which returning true and after that 
calling 
 call_user_func_array([$this, $method_name], $parameters);, and that 
 invocation 
 again sending to __call(), although method buildSql exists and visibled.

that bug already resolved and fixed, autoreplace error. sorry.


[2012-08-18 14:07:27] popsul1993 at gmail dot com

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql' 
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP =5.4.5 have a crazy behavior, i.e. my implementation of ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
buildSql(); that call send to __call(), where there is a checing with code 
method_exists($this, $method_name), which returning true and after that calling 
call_user_func_array([$this, $method_name], $parameters);, and that invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test-foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=optimized out, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=optimized out, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0, 
fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=synthetic pointer, 
error=0xbf8000f4, spec=synthetic pointer, va=0xbf800158, arg=0xb70ad254, 
arg_num=optimized out) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=synthetic pointer, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a fa/, va=0xbf800158, 
flags=0) at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a fa/) 
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/Загрузки/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=optimized 
out)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_vm_execute.h:642
#8  0x083a242d in execute (op_array=optimized out) at /home/popsul/
Загрузки/php-5.4.6/Zend/zend_vm_execute.h:410
#9  

Req #62859 [Opn-Wfx]: Give __construct() the respect it deserves

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=62859edit=1

 ID: 62859
 Updated by: ahar...@php.net
 Reported by:michaelduff2 at yahoo dot com
 Summary:Give __construct() the respect it deserves
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Given that you can already implement factories perfectly well via static 
methods, I can't think of any use for this that doesn't end in making code less 
clear.

If you want a discussion, write an RFC and post it to Internals, but I can't 
see this getting up.


Previous Comments:

[2012-08-18 19:48:01] michaelduff2 at yahoo dot com

Description:

Here's a PHP6 -- or PHP7 ;) request for you; many will scream N, 
but hear me out:

Make it possible to return an object from __construct().

Yeah, I said it. Sounds crazy, but this would make factories more abstract, and 
enables all sorts of magic without user code being any wiser (unless they 
Reflect upon it, I suppose.)

For type safety, the object returned should probably be an instanceof __CLASS__.

If no return() exists, then normal 'new' semantics would apply.

Discuss.







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

Req #62864 [Opn-Fbk]: strftime(%A) with locale set to french outputs date with capital letter

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=62864edit=1

 ID: 62864
 Updated by: ahar...@php.net
 Reported by:pierrelouis dot peeters at gmail dot com
 Summary:strftime(%A) with locale set to french outputs
 date with capital letter
-Status: Open
+Status: Feedback
 Type:   Feature/Change Request
 Package:Date/time related
 Operating System:   Unix
 PHP Version:5.4Git-2012-08-19 (snap)
 Block user comment: N
 Private report: N

 New Comment:

This is almost certainly an issue with your OS locale support, rather than PHP. 
It behaves normally for in Ubuntu 12.04, for instance.

What OS/distribution are you running, and what output do you get from running 
this in a shell: LC_ALL=fr_FR.UTF-8 date (or whatever French locale name is 
correct for your system).


Previous Comments:

[2012-08-19 09:44:47] pierrelouis dot peeters at gmail dot com

Description:

If you put locale to French (fr_FR), strftime outputs the day with a capital 
letter instead of all lowercase (e.g.: it outputs 'Vendredi' instead of 
'vendredi'). In French, days don't have capital letters.

Test script:
---
setlocale(LC_ALL, 'fr_FR');
echo strftime(%A);

Expected result:

The current day in lowercase.

Actual result:
--
The current day with a capital letter.






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

Bug #45404 [Com]: SoapClient.__getTypes don't care about inheritance

[bkfake-php at yahoo dot com]

Edit report at https://bugs.php.net/bug.php?id=45404edit=1

 ID: 45404
 Comment by: bkfake-php at yahoo dot com
 Reported by:oamblet at vmware dot com
 Summary:SoapClient.__getTypes don't care about inheritance
 Status: No Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   MacOSX 10.5
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

I've just encountered this bug/shortcoming.

Thought it deserved a bump

the original report from 4 years ago states this bug makes it hard.
I think the mor accurate word is impossible


Previous Comments:

[2012-05-11 11:40:55] patkoscsaba at syneto dot net

I can confirm this bug is still present with PHP 5.3.10 on OpenIndiana.


[2011-07-19 18:33:14] abel dot silva at gmail dot com

Hello,

I'm having exactly the same problem.
php 5.3.0 on windows


[2011-02-11 08:23:06] ujl at topdanmark dot dk

Hello,

I've same problem. I'm using a WSDL generator which read the WSDL file and the 
extension doesn't work. I've tried with windows PHP 5.2.17 and PHP 5.3.5. Is 
the problem solved on the *nix platform and not Windows?

The problem is extactly the same as described by oamblet 2008-07-01 and I 
didn't understand the issue is not solved in the windows version of PHP??


[2009-05-06 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.


[2009-04-28 18:44:21] j...@php.net

Please try using this CVS snapshot:

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

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






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

https://bugs.php.net/bug.php?id=45404


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

Bug #45404 [NoF-Opn]: SoapClient.__getTypes don't care about inheritance

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=45404edit=1

 ID: 45404
 Updated by: ahar...@php.net
 Reported by:oamblet at vmware dot com
 Summary:SoapClient.__getTypes don't care about inheritance
-Status: No Feedback
+Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   MacOSX 10.5
 PHP Version:5.2.6
 Block user comment: N
 Private report: N



Previous Comments:

[2012-08-20 02:00:04] bkfake-php at yahoo dot com

I've just encountered this bug/shortcoming.

Thought it deserved a bump

the original report from 4 years ago states this bug makes it hard.
I think the mor accurate word is impossible


[2012-05-11 11:40:55] patkoscsaba at syneto dot net

I can confirm this bug is still present with PHP 5.3.10 on OpenIndiana.


[2011-07-19 18:33:14] abel dot silva at gmail dot com

Hello,

I'm having exactly the same problem.
php 5.3.0 on windows


[2011-02-11 08:23:06] ujl at topdanmark dot dk

Hello,

I've same problem. I'm using a WSDL generator which read the WSDL file and the 
extension doesn't work. I've tried with windows PHP 5.2.17 and PHP 5.3.5. Is 
the problem solved on the *nix platform and not Windows?

The problem is extactly the same as described by oamblet 2008-07-01 and I 
didn't understand the issue is not solved in the windows version of PHP??


[2009-05-06 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.




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

https://bugs.php.net/bug.php?id=45404


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

Bug #60097 [Opn-Csd]: token_get_all fails to lex nested heredoc

[stas]

Edit report at https://bugs.php.net/bug.php?id=60097edit=1

 ID: 60097
 Updated by: s...@php.net
 Reported by:ni...@php.net
 Summary:token_get_all fails to lex nested heredoc
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.0beta1
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

fixed by 4cf90e06c9834a52195384da760503ea055c726d in master.


Previous Comments:

[2011-10-19 22:48:51] fel...@php.net

It also causes a memory leak.

[Wed Oct 19 20:41:43 2011]  Script:  '../bug.php'
Zend/zend_language_scanner.l(2113) :  Freeing 0xB73DFBA4 (4 bytes), 
script=../bug.php
=== Total 1 memory leaks detected ===


[2011-10-19 17:06:58] ni...@php.net

Description:

token_get_all('?php
DOC
{$s(ppp
ppp
)}
DOC;
');

Doesn't recognize DOC; as the heredoc end.
Looks like some of the heredoc LEXING code was put in the PARSER.







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

Bug #62844 [Opn-Csd]: parse_url() does not recognize //

[stas]

Edit report at https://bugs.php.net/bug.php?id=62844edit=1

 ID: 62844
 Updated by: s...@php.net
 Reported by:phpqa at sebastianmendel dot de
 Summary:parse_url() does not recognize //
-Status: Open
+Status: Closed
 Type:   Bug
 Package:URL related
 Operating System:   Linux
 PHP Version:5.4.6
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-08-19 23:33:27] ajf at ajf dot me

Added patch and made pull request: https://github.com/php/php-src/pull/169


[2012-08-17 09:59:15] phpqa at sebastianmendel dot de

even if doc says This function doesn't work with relative URLs. it also says: 
Partial URLs are also accepted, parse_url() tries its best to parse them 
correctly.

and it parses relative URLs like /path/file.html?var=1foo=bar#123 correctly


[2012-08-17 09:22:03] phpqa at sebastianmendel dot de

Description:

parse_url() does not recognize '//' as scheme to host separator and therefor 
does 
not recognize exemple.org as host in URL //example.org

Test script:
---
var_dump(parse_url('//example.org'));


Expected result:

array(1) {
  'host' =
  string(11) example.org
}


Actual result:
--
array(1) {
  'path' =
  string(14) //example.org
}








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

Bug #60110 [Opn]: fclose(), file_put_contents(), copy() do not return false properly

[stas]

Edit report at https://bugs.php.net/bug.php?id=60110edit=1

 ID: 60110
 Updated by: s...@php.net
 Reported by:tom at punkave dot com
 Summary:fclose(), file_put_contents(), copy() do not return
 false properly
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   all
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

This looks like a bug, I think it'd be fine to have the fix in 5.4. Any pull 
reqs 
with fixes?


Previous Comments:

[2011-12-30 17:25:04] cataphr...@php.net

fclose() calls php_stream_close since PHP 5.4, see 
http://svn.php.net/viewvc?view=revisionrevision=309491


[2011-12-29 04:45:53] tstarl...@php.net

It would be nice if the return value of php_stream_close() was checked, but 
note that fclose() does not call php_stream_close(), it calls 
zend_list_delete(), which can't return anything sensible because 
rsrc_dtor_func_t returns void.

It would be ugly and difficult to change rsrc_dtor_func_t at this stage, and in 
any case, during shutdown or zval destruction we don't really care about flush 
failures. I think the way to go would be to call php_stream_close() from 
fclose() before calling the resource destructor. There probably won't be any 
dangling pointers, it looks pretty well guarded already.

As for cataphract's concern: we could audit all the wrapper close functions, 
there's not that many of them is there?


[2011-10-24 17:05:00] tom at punkave dot com

How about a close_checks_flush php.ini flag which defaults to false in 5.3 and 
to 
true in 5.4?


[2011-10-21 21:35:52] tom at punkave dot com

This can definitely happen with the regular stdio stuff. stdio employs 
buffering 
as a matter of course. It is a serious bug, not a change in behavior.

As for stream wrappers, the documentation specifies what stream_flush is 
supposed to return, and fflush() would already be failing for people with bad 
stream wrappers who did not heed that documentation.

stream_close is not supposed to return anything but is not affected by this bug 
because stream_flush has already been called (and cheerfully ignored) before 
stream_close is called (I checked). 

So there is no need to change the behavior of stream_close (which would be a bc 
break). We just need to pay attention to what stream_flush is already telling 
us.


[2011-10-21 21:23:22] cataphr...@php.net

See bug #53328. This is a good candidate for trunk, for stable versions I fear 
(perhaps unfoundedly) that, because the return value of php_stream_close/free 
is almost always ignored, some wrappers might have gotten away with incorrect 
return values on the close handler.




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

https://bugs.php.net/bug.php?id=60110


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

Bug #62854 [Opn]: Segfault on call_user_func_array

[laruence]

Edit report at https://bugs.php.net/bug.php?id=62854edit=1

 ID: 62854
 Updated by: larue...@php.net
 Reported by:popsul1993 at gmail dot com
 Summary:Segfault on call_user_func_array
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

is that a stack overflow segfault?


Previous Comments:

[2012-08-20 01:31:32] ahar...@php.net

I think Felipe thought you were talking about the whole bug in the first 
comment, not just that paragraph. Reopened.


[2012-08-18 15:53:24] popsul1993 at gmail dot com

Why that not a bug? Interpreter crashes when recursion is over 
call_user_func_array, and necessary make Fatal Error. IF that code running 
under 
php 5.3 - behavior is correct, and under 5.4 - interpreter crash with segfault.

p.s. Sorry for my English.


[2012-08-18 15:13:21] fel...@php.net

.


[2012-08-18 14:21:34] popsul1993 at gmail dot com

 Also, PHP =5.4.5 have a crazy behavior, i.e. my implementation of 
ActiveRecord 
 have method 'buildSql' (with public visibility), but when run e.g. $this-
buildSql();
 that call send to __call(), where there is a checing with code 
 method_exists($this, $method_name), which returning true and after that 
calling 
 call_user_func_array([$this, $method_name], $parameters);, and that 
 invocation 
 again sending to __call(), although method buildSql exists and visibled.

that bug already resolved and fixed, autoreplace error. sorry.


[2012-08-18 14:07:27] popsul1993 at gmail dot com

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql' 
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP =5.4.5 have a crazy behavior, i.e. my implementation of ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
buildSql(); that call send to __call(), where there is a checing with code 
method_exists($this, $method_name), which returning true and after that calling 
call_user_func_array([$this, $method_name], $parameters);, and that invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test-foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=optimized out, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=optimized out, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0, 
fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=synthetic pointer, 
error=0xbf8000f4, spec=synthetic pointer, va=0xbf800158, arg=0xb70ad254, 
arg_num=optimized out) at /home/popsul/Загрузки/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=synthetic pointer, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a fa/, va=0xbf800158, 
flags=0) at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a fa/) 
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/Загрузки/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=optimized 
out)
at /home/popsul/Загрузки/php-5.4.6/Zend/zend_vm_execute.h:642
#8