Bug #65554 [Opn->Csd]: createFromFormat broken when weekday name is followed by some delimiters

[stas]

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

 ID: 65554
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:createFromFormat broken when weekday name is
 followed by some delimiters
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   *
 PHP Version:5.4.19
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of vlogvins...@cogniance.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=e6424d89e9419e610ea95484081b9c26b0a7c044
Log: Fix bug #65554 in DateTime, when use it with D/l in format and textual day 
have dot at the end


Previous Comments:

[2013-08-25 22:01:46] s...@php.net

Description:

createFromFormat fails when in the format D or l is followed by separators that 
are not space or comma. 

Test script:
---
$string = "Thu., Nov. 29, 2012 5:00PM";

$data = DateTime::createFromFormat( "D., M# j, Y g:iA", $string );

var_dump( $data );
var_dump( DateTime::getLastErrors() );

Expected result:

object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2012-11-29 17:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(19) "America/Los_Angeles"
}
array(4) {
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(0)
  ["errors"]=>
  array(0) {
  }
}


Actual result:
--
bool(false)
array(4) {
  ["warning_count"]=>
  int(0)
  ["warnings"]=>
  array(0) {
  }
  ["error_count"]=>
  int(2)
  ["errors"]=>
  array(2) {
[0]=>
string(32) "A textual day could not be found"
[4]=>
string(40) "The separation symbol could not be found"
  }
}







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

Bug #65483 [Opn->Csd]: quoted-printable encode stream filter incorrectly encoding spaces

[stas]

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

 ID: 65483
 Updated by: s...@php.net
 Reported by:slusarz at curecanti dot org
 Summary:quoted-printable encode stream filter incorrectly
 encoding spaces
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   Linux
 PHP Version:5.4.18
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of slus...@curecanti.org
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=3f9af558e78c9904f72933dfb3c735a9d2119b52
Log: Fix #65483: quoted-printable encode stream filter incorrectly encoding 
spaces


Previous Comments:

[2013-08-20 07:00:52] slusarz at curecanti dot org

Description:

Due to fix for #64166, the encode stream filter is now incorrectly encoding ALL 
space characters after the first encoded character.

E.g.:

'a b=c d'

Should be encoded:

'a b=3Dc d'

But is now encoded:

'a b=3Dc=20d'

Patch to be uploaded to github shortly.







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

Bug #65497 [Opn]: All tests are failing

[stas]

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

 ID: 65497
 Updated by: s...@php.net
 Reported by:cmbecker69 at gmx dot de
 Summary:All tests are failing
 Status: Open
 Type:   Bug
-Package:Testing related
+Package:*Compile Issues
 Operating System:   Cygwin
 PHP Version:5.5.2
 Block user comment: N
 Private report: N

 New Comment:

This looks like some environment problem. PHP does not load its own shared 
libs, 
so whatever is going wrong is going wrong either in the compiler or in the 
environment. If you're getting this message with tests but not when you run 
either -v or -i, the difference may be either php.ini or some environment vars.


Previous Comments:

[2013-08-21 22:40:37] cmbecker69 at gmx dot de

For most development I'm using "normal" Windows builds,
but for some experiments I prefer the Unix toolchain,
so Cygwin comes in handy (I could use a virtual machine,
but it seems a bit heavyweight).

I should have noted in the first place that the compiled
PHP seems to run fine; at least I haven't noticed any issues
yet (neither CLI nor CGI).

basic/001.out:
  /home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading
  shared libraries: ?: cannot open shared object file: No 
  such file or directory

The other .out files have the same message (I've checked 
only a handful, however).


[2013-08-21 21:57:46] johan...@php.net

Cygwin is a complicated platform, any reason you're not using "normal" Windows 
or some "normal"  Unix/linux?

That aside: There shouldn't be any dll's or so's being built. Can you please 
check the created .out / .diff files from the tests to see whether the report 
any specific error? If they run at all PHP can't be totally broken as the test 
runner is using PHP, too. I guess it is some php.ini related error.


[2013-08-21 21:38:01] cmbecker69 at gmx dot de

Description:

After compiling PHP 5.5.2 on Cygwin[1] all tests 
of the accompanying test suite are failing.

This might be related to the shared libraries, which don't seem
to be properly build on Cygwin (.so instead of .dll.a, with a filesize
of less than 1 KB).

[1] $ uname -a
CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin


Test script:
---
./configure --enable-opcache=no
make
make test

Expected result:

The tests succeed.

Actual result:
--
All tests fail.






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

Bug #63520 [Asn]: JSON extension includes a problematic license statement

[stas]

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

 ID: 63520
 Updated by: s...@php.net
 Reported by:kaplan at debian dot org
 Summary:JSON extension includes a problematic license
 statement
 Status: Assigned
 Type:   Bug
 Package:JSON related
 PHP Version:Irrelevant
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

How this is a PHP bug?


Previous Comments:

[2013-07-17 15:18:33] r...@php.net

@seld Mandriva/Fedora/Debian have drop json non-free extension but provides 
jsonc dropin alternative (php5-json 1.3.1 for debian).

So, your comment is not PHP related. See debian packager to have this package 
installed when needed (pulled by main php package for Fedora).


[2013-07-17 14:24:32] s...@php.net

What's the status here Remi? Can we have a regular Debian release including the 
JSON ext before this hits testing/stable? We had a first issue on Composer 
today because someone was missing the json ext [1], using Ubuntu 13.10. 

If this isn't resolved soon Ubuntu's next release won't have json enabled by 
default and we'll have a support shitstorm on our hands, so please don't do 
Evil because of a dubious license statement. Given the prevalence of JSON APIs 
and such these days, it's not just Composer that will be affected, so removing 
it before having a replacement in place was really an unhelpful decision IMO.

[1] https://github.com/composer/composer/issues/2092


[2013-04-27 10:40:22] r...@php.net

Yes, I'm still working on the new alternative extension.


[2013-04-22 22:24:39] pleasestand at live dot com

Remi: any update? Is 
relevant?

I'll note that as a [MediaWiki][1] developer, I recently removed our
bundled copy of PEAR Services_JSON on the basis that the JSON extension
is compiled in by default, and therefore users can be expected to have
it installed. Unfortunately, I had to [revert the change][2] because
I only found out about the licensing problem last week, and our next
release is three weeks from now (2013-05-15).

So I would like to know whether you are still working on this.

[1]: https://www.mediawiki.org/
[2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=47431


[2013-04-04 18:00:52] b dot eltzner at gmx dot de

I am not a native speaker. This comment is not supposed to be rude or insult 
anybody.

I would like to make the problem clearer:

*The "json license" affecting /ext/json/JSON_parser.c and 
/ext/json/utf8_decode.c is regarded non-free by GNU/FSF, Debian, Fedora, Red 
Hat and Google and is not approved by OSI. This is not at all the same as "Free 
but incompatible with GPL", which is the category in which the FSF lists the 
php license.

*The morality clause "The Software shall be used for Good, not Evil." violates 
software freedom 0 and point 6 of the open source definition and the license 
will therefore _never_ be free or open source by definition. This is not a 
license "some fanatics don't like", it is a manifestly proprietary license.

*The original author of the license has purposely chosen this form of license 
to trick open source projects into mistaking it as an open source license. He 
did this to prove the point that "those open source guys are entitled kids" and 
plays the issue for amusement: http://www.youtube.com/watch?v=-hCimLnIsDA

*With the non-free files, PHP cannot be distributed unmodified as free software 
by downstream projects.

Note that I don't say "Throw that stuff out11" It goes without saying that 
you can distribute the result of your work under whatever licenses you like, 
open source or not. However, if you want PHP to be easily distributable as free 
and open source software by downstream projects, I am sure they would be 
enormously relieved, if you provided them with a simple way to exclude the 
non-free files without breaking too much functionality.




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=63520


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

Bug #65460 [Asn->Csd]: PHP 5.4.18 fails to compile with Apache 2.4.6

[stas]

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

 ID: 65460
 Updated by: s...@php.net
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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:

[2013-08-19 18:34:44] ben dot harper at rackspace dot com

Like giamteckchoon, I did not get this error with this solution on RHEL 6, but 
not RHEL 5.  I get the following error:

+ rm Zend/zend_language_parser.c Zend/zend_language_parser.h 
Zend/zend_ini_parser.c Zend/zend_ini_parser.h
+ ./genfiles   
Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' 
Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier   

I updated the patch to the following to get around this error:

$ cat SOURCES/php-5.4.18-bison.patch 
diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index ccbc9b1..6a9a24a 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -41,17 +41,19 @@ static YYSIZE_T zend_yytnamerr(char*, const char*);
 
 #define YYERROR_VERBOSE
 #define YYSTYPE znode
-#ifdef ZTS
-# define YYPARSE_PARAM tsrm_ls
-# define YYLEX_PARAM tsrm_ls
-#endif
-
 
 %}
 
 %pure_parser
 %expect 3
 
+%{
+#ifdef ZTS
+# define YYPARSE_PARAM tsrm_ls
+# define YYLEX_PARAM tsrm_ls
+#endif
+%}
+
 %token END 0 "end of file"
 %left T_INCLUDE T_INCLUDE_ONCE T_EVAL T_REQUIRE T_REQUIRE_ONCE
 %token T_INCLUDE  "include (T_INCLUDE)"


Does this change seem sane?


[2013-08-19 17:46:04] s...@php.net

OK, looks like the patch for bug #64503 should be applied to 5.4 too for it to 
work with bison 2.7.


[2013-08-19 13:48:16] stu at coe dot uky dot edu

Applying the patch (at 
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build_2.patch&revision=latest)
 and doing the other steps:
rm Zend/zend_{language,ini}_parser.[ch]
./genfiles
fixed the problem.

FYI Slackware 14.0 ships with bison (GNU Bison) 2.5.1

Thanks to all!


[2013-08-19 12:05:32] r...@php.net

I think this is the same issue than #64503, caused by the switch from Bison 2.3 
to 2.7, used to generate the parser.

Notice : the fix for this issue have only been applied in 5.5 tree.


[2013-08-19 07:37:04] m...@php.net

Sorry for not being explicit enough!

I can reproduce with 

$ ./configure --enable-maintainer-zts --disable-all --prefix=$(pwd)/usr 

so, enabling ZTS should cause the 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=65460


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

Bug #65460 [Asn]: PHP 5.4.18 fails to compile with Apache 2.4.6

[stas]

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

 ID: 65460
 Updated by: s...@php.net
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

OK, looks like the patch for bug #64503 should be applied to 5.4 too for it to 
work with bison 2.7.


Previous Comments:

[2013-08-19 13:48:16] stu at coe dot uky dot edu

Applying the patch (at 
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build_2.patch&revision=latest)
 and doing the other steps:
rm Zend/zend_{language,ini}_parser.[ch]
./genfiles
fixed the problem.

FYI Slackware 14.0 ships with bison (GNU Bison) 2.5.1

Thanks to all!


[2013-08-19 12:05:32] r...@php.net

I think this is the same issue than #64503, caused by the switch from Bison 2.3 
to 2.7, used to generate the parser.

Notice : the fix for this issue have only been applied in 5.5 tree.


[2013-08-19 07:37:04] m...@php.net

Sorry for not being explicit enough!

I can reproduce with 

$ ./configure --enable-maintainer-zts --disable-all --prefix=$(pwd)/usr 

so, enabling ZTS should cause the issue.


[2013-08-19 07:10:26] s...@php.net

Mike, so which options should I use to reproduce it? Because I used with-apxs2 
and it worked fine. Should apache be built with some special options? IIRC, it 
usually does not build ZTS version, so what is the config for you that doesn't 
work?


[2013-08-19 07:03:45] m...@php.net

I also doubt that it's about Apache, but rather about ZTS.  Looking at the 
tarball files I see:

in zend_global_macros.h:
/* Compiler */
#ifdef ZTS
# define CG(v) TSRMG(compiler_globals_id, zend_compiler_globals *, v)
int zendparse(void *compiler_globals);
#else
# define CG(v) (compiler_globals.v)
extern ZEND_API struct _zend_compiler_globals compiler_globals;
int zendparse(void);
#endif


Note the #ifdef ZTS zendparse declaration



...and in zend_language_parser.h:


#ifdef YYPARSE_PARAM
#if defined __STDC__ || defined __cplusplus
int zendparse (void *YYPARSE_PARAM);
#else
int zendparse ();
#endif
#else /* ! YYPARSE_PARAM */
#if defined __STDC__ || defined __cplusplus
int zendparse (void);
#else
int zendparse ();
#endif
#endif /* ! YYPARSE_PARAM */

...where YYPARSE_PARAM is defined in the source (.c) file.




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=65460


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

Bug #65460 [Asn]: PHP 5.4.18 fails to compile with Apache 2.4.6

[stas]

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

 ID: 65460
 Updated by: s...@php.net
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

Mike, so which options should I use to reproduce it? Because I used with-apxs2 
and it worked fine. Should apache be built with some special options? IIRC, it 
usually does not build ZTS version, so what is the config for you that doesn't 
work?


Previous Comments:

[2013-08-19 07:03:45] m...@php.net

I also doubt that it's about Apache, but rather about ZTS.  Looking at the 
tarball files I see:

in zend_global_macros.h:
/* Compiler */
#ifdef ZTS
# define CG(v) TSRMG(compiler_globals_id, zend_compiler_globals *, v)
int zendparse(void *compiler_globals);
#else
# define CG(v) (compiler_globals.v)
extern ZEND_API struct _zend_compiler_globals compiler_globals;
int zendparse(void);
#endif


Note the #ifdef ZTS zendparse declaration



...and in zend_language_parser.h:


#ifdef YYPARSE_PARAM
#if defined __STDC__ || defined __cplusplus
int zendparse (void *YYPARSE_PARAM);
#else
int zendparse ();
#endif
#else /* ! YYPARSE_PARAM */
#if defined __STDC__ || defined __cplusplus
int zendparse (void);
#else
int zendparse ();
#endif
#endif /* ! YYPARSE_PARAM */

...where YYPARSE_PARAM is defined in the source (.c) file.


[2013-08-19 00:28:49] s...@php.net

5.4 compiles fine for me on CentOS 6.3 and on Mac. Apache is older there but I 
don't think this should have any consequence for zendparse.


[2013-08-18 19:11:35] m...@php.net

Looks like something was wrongly or not completely merged into 5.4?


[2013-08-18 02:16:58] giamteckchoon at gmail dot com

I overcome this error by following the steps outline in 
https://bugs.php.net/bug.php?id=64503 (note you need to install bison):

1. Apply the patch at 
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build_2.patch&revision=latest

2. rm -f Zend/zend_{language,ini}_parser.[ch]

3. Regenerate Zend/zend_language_parser.c etc.
./genfiles

4. Compile as usual.

Tested in SL6.4/CentOS6.4.

Hope this helps!


[2013-08-16 16:59:25] ben dot harper at rackspace dot com

I am running into this same error on RHEL 5 with Apache 2.2.3 and RHEL 6 with 
2.2.15.  Same config on both but slightly different error:

%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--with-xpm-dir=%{_prefix} \
--enable-gd-native-ttf \
--with-t1lib=%{_prefix} \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-pcre-regex \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
--with-mhash \

Error in RHEL 5:

In file included from /builddir/build/BUILD/php-
5.4.18/ext/standard/basic_functions.c:48:
/builddir/build/BUILD/php-5.4.18/Zend/zend_language_parser.h:327: error: 
conflicting types for 'zendparse'
/builddir/build/BUILD/php-5.4.18/Zend/zend_globals_macros.h:35: error: previous 
declaration of 'zendparse' was here
/bin/sh /builddir/build/BUILD/php-5.4.18/build-ztscli/libtool --silent --
preserve-dup-deps --mode=compile /builddir/build/BUILD/php-5.4.18/build-
ztscli/meta_ccld  -Iext/standard/ -I/builddir/build/BUILD/php-
5.4.18/ext/standard/ -DPHP_ATOM_INC -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/include -I/builddir/build/BUILD/php-5.4.18/build-ztscli/main -
I/builddir/build/BUILD/php-5.4.18 -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/date/lib -I/builddir/build/BUILD/php-5.4.18/ext/date/lib -
I/builddir/build/BUILD/php-5.4.18/ext/ereg/regex -I/usr/include/libxml2 -
I/usr

Bug #48874 [Opn->Csd]: Sample php.ini misleading include reference to php_zip.dll

[stas]

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

 ID: 48874
 Updated by: s...@php.net
 Reported by:ben at imperialwebdesigns dot com
 Summary:Sample php.ini misleading include reference to
 php_zip.dll
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Zip Related
 Operating System:   win32 only - Windows 2003 Server
 PHP Version:5.3.0
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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:

[2009-07-09 16:14:57] ben at imperialwebdesigns dot com

Description:

The sample INI files distributed with PHP 5.3.0 for windows references 
php_zip.dll in the extensions section.  This extension appears to be compiled 
into the core so this line is misleading.

Specifically the line is:
;extension=php_zip.dll







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

Bug #65460 [Asn]: PHP 5.4.18 fails to compile with Apache 2.4.6

[stas]

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

 ID: 65460
 Updated by: s...@php.net
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

5.4 compiles fine for me on CentOS 6.3 and on Mac. Apache is older there but I 
don't think this should have any consequence for zendparse.


Previous Comments:

[2013-08-18 19:11:35] m...@php.net

Looks like something was wrongly or not completely merged into 5.4?


[2013-08-18 02:16:58] giamteckchoon at gmail dot com

I overcome this error by following the steps outline in 
https://bugs.php.net/bug.php?id=64503 (note you need to install bison):

1. Apply the patch at 
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build_2.patch&revision=latest

2. rm -f Zend/zend_{language,ini}_parser.[ch]

3. Regenerate Zend/zend_language_parser.c etc.
./genfiles

4. Compile as usual.

Tested in SL6.4/CentOS6.4.

Hope this helps!


[2013-08-16 16:59:25] ben dot harper at rackspace dot com

I am running into this same error on RHEL 5 with Apache 2.2.3 and RHEL 6 with 
2.2.15.  Same config on both but slightly different error:

%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--with-xpm-dir=%{_prefix} \
--enable-gd-native-ttf \
--with-t1lib=%{_prefix} \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-pcre-regex \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
--with-mhash \

Error in RHEL 5:

In file included from /builddir/build/BUILD/php-
5.4.18/ext/standard/basic_functions.c:48:
/builddir/build/BUILD/php-5.4.18/Zend/zend_language_parser.h:327: error: 
conflicting types for 'zendparse'
/builddir/build/BUILD/php-5.4.18/Zend/zend_globals_macros.h:35: error: previous 
declaration of 'zendparse' was here
/bin/sh /builddir/build/BUILD/php-5.4.18/build-ztscli/libtool --silent --
preserve-dup-deps --mode=compile /builddir/build/BUILD/php-5.4.18/build-
ztscli/meta_ccld  -Iext/standard/ -I/builddir/build/BUILD/php-
5.4.18/ext/standard/ -DPHP_ATOM_INC -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/include -I/builddir/build/BUILD/php-5.4.18/build-ztscli/main -
I/builddir/build/BUILD/php-5.4.18 -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/date/lib -I/builddir/build/BUILD/php-5.4.18/ext/date/lib -
I/builddir/build/BUILD/php-5.4.18/ext/ereg/regex -I/usr/include/libxml2 -
I/usr/kerberos/include -I/usr/include/enchant -I/usr/include/freetype2 -
I/usr/include/imap -I/usr/lib/firebird/include -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/oniguruma -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/oniguruma -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/libmbfl -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/libmbfl -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/libmbfl/mbfl -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/libmbfl/mbfl -I/usr/include/pspell -
I/builddir/build/BUILD/php-5.4.18/build-ztscli/TSRM -I/builddir/build/BUILD/php-
5.4.18/build-ztscli/Zend -I/builddir/build/BUILD/php-5.4.18/main -
I/builddir/build/BUILD/php-5.4.18/Zend -I/builddir/build/BUILD/php-5.4.18/TSRM -
I/builddir/build/BUILD/php-5.4.18/build-ztscli/  -D_REENTRANT  -I/usr/include -
O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --
param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-
tables -fno-strict-aliasing -Wno-pointer-sign -fvisibility=hidden -pthread 
-DZTS  
-c /builddir/build/BUILD/php-5.4.18/ext/standard/filestat.c -o 
ext/standard/filestat.lo 
make: *** [ext/standard/basic_functions.lo] Error 1
make: *** Waiting for unfinished jobs
/builddir/build/BUILD/php-5.4

Bug #65470 [Opn->Csd]: Segmentation fault in zend_error() with --enable-dtrace

[stas]

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

 ID: 65470
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:Segmentation fault in zend_error() with
 --enable-dtrace
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4Git-2013-08-18 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=14f5732096575f3c4ff0438e6650238370cb465c
Log: Fix bug #65470 Segmentation fault in zend_error() with --enable-dtrace


Previous Comments:

[2013-08-18 06:02:12] s...@php.net

The patch tested OK and can be applied to PHP 5.4, 5.5 and master.  This 
requires 
zend karma, which I don't have.


[2013-08-18 05:05:12] s...@php.net

The following patch has been added/updated:

Patch Name: bug65470
Revision:   1376802312
URL:
https://bugs.php.net/patch-display.php?bug=65470&patch=bug65470&revision=1376802312


[2013-08-18 04:41:33] s...@php.net

I'm currently testing a patch.


[2013-08-18 04:40:25] s...@php.net

Description:

A segmentation fault can occur in zend_error() with --enable-dtrace.
The zend_vspprintf() call in the DTRACE_ERROR_ENABLED() block leaves
args undefined:

  "If ap is passed to a function that uses va_arg(ap,type) then the
  value of ap is undefined after the return of that function."

When args is used again later in zend_error(), a seg fault can occur.

Test script:
---
As root:
---
# dtrace -Z -s error.d 
dtrace: script 'error.d' matched 0 probes
CPU IDFUNCTION:NAME
  0  6 zend_error:error PHP error



As a normal user:

$ php error.php 
Segmentation fault (core dumped)


Where error.d is:

php*:::error { printf("PHP error\n"); }

and error.php is:










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

Bug #65225 [Opn->Csd]: PHP_BINARY incorrectly set

[stas]

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

 ID: 65225
 Updated by: s...@php.net
 Reported by:patrickalla...@php.net
 Summary:PHP_BINARY incorrectly set
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHP options/info functions
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=0154db1c5fcfd0c4030a0aefb2861dc8386b4a1c
Log: new for fix #65225


Previous Comments:

[2013-07-09 13:02:36] patrickalla...@php.net

Description:

PHP_BINARY is initialized thanks to php_binary_init() without checking that 
candidate is a regular file.

I'm going to send a pull request that fixes it.

Test script:
---
$ sudo mkdir /usr/local/bin/php
$ php -r 'echo PHP_BINARY, "\n";';


Expected result:

/usr/lib64/php5.4/bin/php


Actual result:
--
/usr/local/bin/php






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

Bug #65382 [Asn]: Segfault in closure_030.phpt

[stas]

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

 ID: 65382
 Updated by: s...@php.net
 Reported by:ni...@php.net
 Summary:Segfault in closure_030.phpt
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.5.2RC1
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Looks like consequence of 821d7169d9d575ceef71e69570b98519826ccb01 - prototype 
is 
being use as temp storage, but it is actually never reset. If I add:

op_array->prototype = NULL;

to zend_leave_helper_SPEC, it looks like it fixes the crash, but I'm not sure 
if 
it is the right thing to do (e.g. - what happens if such calls are nested?)


Previous Comments:

[2013-08-11 08:18:35] s...@php.net

Looks like refcount for $b is decremented twice in the last call - once in 
zend_leave_helper_SPEC and once when finishing 
zend_do_fcall_common_helper_SPEC, 
which causes $b to be destroyed. This code was added by Dmitry, so assigning 
this 
bug to him.


[2013-08-03 12:45:43] ni...@php.net

Description:

closure_030.phpt segfaults on Travis.

Short repro script:

__invoke();

Valgrind output:

~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php 
==2074== Memcheck, a memory error detector
==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2074== Command: sapi/cli/php t22.php
==2074== 
==2074== Invalid read of size 1
==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203)
==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775)
==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217)
==2074==by 0x8274BC3: zend_call_destructors (zend.c:923)
==2074==by 0x81D6742: php_request_shutdown (main.c:1745)
==2074==by 0x831EDD9: do_cli (php_cli.c:1177)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074==  Address 0x44828f4 is 12 bytes inside a block of size 20 free'd
==2074==at 0x402B06C: free (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2074==by 0x823C602: _efree (zend_alloc.c:2437)
==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82)
==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:630)
==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:682)
==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356)
==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381)
==2074==by 0x827636C: zend_execute_scripts (zend.c:1316)
==2074==by 0x81D85C6: php_execute_script (main.c:2484)
==2074==by 0x831E192: do_cli (php_cli.c:994)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074== 
==2074== Invalid read of size 4
==2074==at 0x825F4F3: zval_refcount_p (zend.h:397)
==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203)
==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775)
==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217)
==2074==by 0x8274BC3: zend_call_destructors (zend.c:923)
==2074==by 0x81D6742: php_request_shutdown (main.c:1745)
==2074==by 0x831EDD9: do_cli (php_cli.c:1177)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074==  Address 0x44828f0 is 8 bytes inside a block of size 20 free'd
==2074==at 0x402B06C: free (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2074==by 0x823C602: _efree (zend_alloc.c:2437)
==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82)
==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:630)
==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:682)
==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356)
==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381)
==2074==by 0x827636C: zend_execute_scripts (zend.c:1316)
==2074==by 0x81D85C6: php_execute_script (main.c:2484)
==2074==by 0x831E192: do_cli (php_cli.c:994)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074== 
... and so on







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

Bug #65382 [Opn]: Segfault in closure_030.phpt

[stas]

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

 ID: 65382
 Updated by: s...@php.net
 Reported by:ni...@php.net
 Summary:Segfault in closure_030.phpt
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.5.2RC1
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Looks like refcount for $b is decremented twice in the last call - once in 
zend_leave_helper_SPEC and once when finishing 
zend_do_fcall_common_helper_SPEC, 
which causes $b to be destroyed. This code was added by Dmitry, so assigning 
this 
bug to him.


Previous Comments:

[2013-08-03 12:45:43] ni...@php.net

Description:

closure_030.phpt segfaults on Travis.

Short repro script:

__invoke();

Valgrind output:

~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php 
==2074== Memcheck, a memory error detector
==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2074== Command: sapi/cli/php t22.php
==2074== 
==2074== Invalid read of size 1
==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203)
==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775)
==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217)
==2074==by 0x8274BC3: zend_call_destructors (zend.c:923)
==2074==by 0x81D6742: php_request_shutdown (main.c:1745)
==2074==by 0x831EDD9: do_cli (php_cli.c:1177)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074==  Address 0x44828f4 is 12 bytes inside a block of size 20 free'd
==2074==at 0x402B06C: free (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2074==by 0x823C602: _efree (zend_alloc.c:2437)
==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82)
==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:630)
==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:682)
==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356)
==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381)
==2074==by 0x827636C: zend_execute_scripts (zend.c:1316)
==2074==by 0x81D85C6: php_execute_script (main.c:2484)
==2074==by 0x831E192: do_cli (php_cli.c:994)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074== 
==2074== Invalid read of size 4
==2074==at 0x825F4F3: zval_refcount_p (zend.h:397)
==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203)
==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775)
==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217)
==2074==by 0x8274BC3: zend_call_destructors (zend.c:923)
==2074==by 0x81D6742: php_request_shutdown (main.c:1745)
==2074==by 0x831EDD9: do_cli (php_cli.c:1177)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074==  Address 0x44828f0 is 8 bytes inside a block of size 20 free'd
==2074==at 0x402B06C: free (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2074==by 0x823C602: _efree (zend_alloc.c:2437)
==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82)
==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:630)
==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:682)
==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356)
==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381)
==2074==by 0x827636C: zend_execute_scripts (zend.c:1316)
==2074==by 0x81D85C6: php_execute_script (main.c:2484)
==2074==by 0x831E192: do_cli (php_cli.c:994)
==2074==by 0x831F6EC: main (php_cli.c:1378)
==2074== 
... and so on







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

Bug #39858 [Csd->ReO]: Lost connection to MySQL server during query by a repeated call stored proced

[stas]

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

 ID: 39858
 Updated by: s...@php.net
 Reported by:develar at gmail dot com
 Summary:Lost connection to MySQL server during query by a
 repeated call stored proced
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:PDO related
-Operating System:   Windows XP SP2
+Operating System:   *
 PHP Version:5.2.0
 Assigned To:wez
 Block user comment: N
 Private report: N

 New Comment:

Still seeing this problem in test bug_39858. See:

https://travis-ci.org/php/php-src/builds/10062028

and also on my local Linux, 64-bit, produces this on master:

Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error in 
/home/smalyshev/php-src/ext/pdo_mysql/tests/bug_39858.php on line 22

Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error in 
/home/smalyshev/php-src/ext/pdo_mysql/tests/bug_39858.php on line 28


Previous Comments:

[2008-09-12 23:02:00] johan...@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.

Fixed when using mysqlnd (Windows default, else, --with-pdo-mysql=mysqlnd)


[2008-08-28 09:34:01] sakha5413 at gmail dot com

Fatal error: SQLSTATE[HY000]: General error: 2014 Cannot execute queries while 
other unbuffered queries are active. Consider using PDOStatement::fetchAll(). 
Alternatively, if your code is only ever going to run against mysql, you may 
enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY 
attribute. in C:\xampp\htdocs\tshirtshop\business\database_handler.php on line 
102


[2008-07-21 15:06:16] jpmasseria at hotmail dot com

The single line workaround worked for me!

while (mysqli_next_result($conn));

Thank you bepoteat!

This is much better than my previous workaround which was to close and reopen 
my database connection before my subsequent stored procedure call.

John


[2008-07-14 15:31:00] ile at suomi dot finland

This bug occurs with Apache/2.0.63 (Win32) PHP/5.2.6 and MySQL 5.0.51b.

I don't use PDO. I use mysqli calls.

The work-around by bepoteat helps though.


[2008-05-02 16:48:43] bepoteat at yahoo dot com

After looking at the PHP manual, I realized I could reduce the loop to a single 
line:

while (mysqli_next_result($conn));

I didn't even have to use mysqli_free_result (but it is good practice).




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=39858


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

Bug #41997 [NoF->ReO]: pdo_mysql: stored procedure call returning single rowset blocks future queries

[stas]

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

 ID: 41997
 Updated by: s...@php.net
 Reported by:nitel_defect at yahoo dot com
 Summary:pdo_mysql: stored procedure call returning single
 rowset blocks future queries
-Status: No Feedback
+Status: Re-Opened
 Type:   Bug
 Package:PDO related
-Operating System:   Windows XP SP2
+Operating System:   *
 PHP Version:5.2.3
 Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

I still see test bug_41997 failing for me on master. Same happens on tracis CI: 

https://travis-ci.org/php/php-src/builds/10062028

Error message is:

Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error in 
/home/smalyshev/php-src/ext/pdo_mysql/tests/bug_41997.php on line 10

Client library version is:

pdo_mysql
Client API version => mysqlnd 5.0.11-dev - 20120503 - $Id: 
40933630edef551dfaca71298a83fad8d03d62d4 $


Previous Comments:

[2008-07-30 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2008-07-22 14:40:38] u...@php.net

Please make sure that you try this with PHP 5.3+ and mysqlnd 
(--with-pdo-mysql=mysqlnd , default). It might not work when using the 
mysqlclient library (libmysql, --with-pdo-mysql=/path/to/mysql_config)


[2008-07-22 14:38:17] u...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi




[2008-05-22 17:32:37] u...@php.net

The next PDO_MYSQLND release should fix this


[2008-01-24 11:46:34] ben at stickyeyes dot com

Just to add to this bug, I too experience this problem when trying to execute 
two stored procedures, one after the other. 

Unfortunately, the only work around I could get working, was to create a new 
PDO object for each query (attempting to clone an existing PDO object caused 
Apache to crash, but thats another bug for another day...)

Sucks, but it works.

Apache/2.2.4 (Win32) PHP/5.2.3
PDO Driver for MySQL, client library version5.0.37
MySQL 5.1.22




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=41997


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

Bug #61345 [Asn->Csd]: CGI mode - make install don't work

[stas]

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

 ID: 61345
 Updated by: s...@php.net
 Reported by:sites at evoluons dot net
 Summary:CGI mode - make install don't work
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Fedora 16 x86_64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of m...@heimpold.de
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=36b759d1dd0258859d247997b9c81727531ce1ba
Log: Fix #61345: fix install of CGI binary


Previous Comments:

[2012-06-16 20:24:44] streaky at mybrokenlogic dot com

Same problem with 5.4.4 on Debian - seems that if you --disable-cli and cgi is 
enabled *and* your EPREFIX/bin isn't already created - then `make install` 
doesn't create them.

If you mkdir EPREFIX/bin those directories then `make install` it all works 
fine - it even creates EPREFIX/include, EPREFIX/lib et al - it's just the bin 
that it seems to miss. To confirm I checked and created EPREFIX before make 
install - and it still falls over EPREFIX/bin.

This used to work fine with 5.3 builds, it is switching to 5.4.4 on a test 
server 'breaks' my build scripts.


[2012-04-26 17:15:26] lzsiga at freemail dot c3 dot hu

Try to execute this command manually

touch /usr/local/phpcgi/bin/#INST@1706#

if you get an error-message, please paste it in here.


[2012-04-25 20:55:50] kuteninja at gmail dot com

I have this same issue, creating php/bin directory make install works, without 
it it doesn't work.

I'm running CentOS 6 x86_64 (so it should be equal in RHEL6 too)

This is my configure:

./configure  --prefix=/usr/local/php --with-layout=GNU --with-config-file-
path=/usr/local/php --disable-all --enable-libxml --with-libxml-dir=/usr/local -
-with-regex=php --enable-cgi --disable-cli --enable-inline-optimization --with-
pcre-regex --enable-json


Only by making the /usr/local/php/bin directory manually I'm able to "make 
install" it.


[2012-03-23 06:32:08] sites at evoluons dot net

I apologize : it's with another computer it was OK.

I updated mine too, and it keep same error.

I tried today with a new ./configure command :

./configure --with-apxs2=/usr/local/apache/bin/apxs 
--with-config-file-path=/usr/local/apache/conf --with-gd --with-zlib --with-bz2 
--enable-ftp --enable-sockets --with-curl --with-mysql=/usr/local/mysql 
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-imap --enable-mbstring 
--enable-exif --without-pear --enable-zip --prefix=/usr/local/php --with-mcrypt 
--with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf 
--with-kerberos --with-imap-ssl

Same problem :
make install
Installing PHP CGI binary:/usr/local/phpcgi/bin/
cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1706#': No such 
file or directory

And if I create folders myself :
mkdir /usr/local/phpcgi
mkdir /usr/local/phpcgi/bin

It's ok :
make install
Installing PHP CGI binary:/usr/local/phpcgi/bin/
Installing build environment: /usr/local/phpcgi/lib/php/build/
Installing header files:  /usr/local/phpcgi/include/php/
Installing helper programs:   /usr/local/phpcgi/bin/
  program: phpize
  program: php-config
Installing man pages: /usr/local/phpcgi/php/man/man1/
  page: phpize.1
  page: php-config.1
Installing PDO headers:  /usr/local/phpcgi/include/php/ext/pdo/


[2012-03-22 08:30:35] sites at evoluons dot net

I updated my Fedora 16 x86_64 and now it works directly, without any workaround.

So, I close the bug.




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=61345


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

Bug #51043 [ReO->Fbk]: apache crashes on php return statement

[stas]

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

 ID: 51043
 Updated by: s...@php.net
 Reported by:php at lokedupont dot info
 Summary:apache crashes on php return statement
-Status: Re-Opened
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OS X Snow leopard
 PHP Version:5.4.17
 Assigned To:stas
 Block user comment: N
 Private report: N



Previous Comments:

[2013-08-08 10:58:32] yohg...@php.net

This sounds like recently fix issue. If anyone experienced similar crash, 
please 
try git versions.


[2013-08-08 10:55:58] yohg...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

admin at vodoo dot ro, could send backtrace?


[2013-08-08 10:34:31] admin at vodoo dot ro

I have the same issue, Zend_auth and the following php version:
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 16:48:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies


[2010-09-01 20:07:10] s...@php.net

If you still have repro example (with zf is ok) and it works with latest 5.3 
build please send it to me.


[2010-04-25 20:03:12] fel...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-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=51043


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

Bug #65028 [Opn->Csd]: Phar::buildFromDirectory creates corrupt archives for some specific contents

[stas]

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

 ID: 65028
 Updated by: s...@php.net
 Reported by:matthias dot burtscher at fusonic dot net
 Summary:Phar::buildFromDirectory creates corrupt archives
 for some specific contents
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHAR related
 Operating System:   Ubuntu 13.04, Windows 7
 PHP Version:5.3.x, 5.4.x, 5.5.x
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f8efdc2b4bca2a8f7e57aae36a01df044ba3d0b5
Log: fix bug #65028 Phar::buildFromDirectory creates corrupt archives for 
some specific contents


Previous Comments:

[2013-07-22 08:02:19] s...@php.net

Matthias, please check if https://github.com/php/php-src/pull/392 fixes your 
problem?


[2013-07-22 07:27:49] s...@php.net

This is a funny one. Seems to be because phar writes the archive this way:

METADATA_HEADER

Where METADATA_HEADER contains phar metadata, first 4 bytes being metadata 
length. However, when phar reads the file, it checks if "__HALT_COMPILER(); ?>" 
is followed by \r, and if there's \r it also looks for \n. Now imagine what 
happens if metadata length is such that its first byte is 0x0D, but second byte 
is not 0x0A? Phar file is not readable anymore.


[2013-06-28 05:59:09] matthias dot burtscher at fusonic dot net

I managed to recreate the issue and submitted a test case right here on GitHub:
https://github.com/php/php-src/pull/371


[2013-06-27 11:59:34] matthias dot burtscher at fusonic dot net

Re-tested with the latest PHP 5.5.0 release, still not working.


[2013-06-13 14:10:01] matthias dot burtscher at fusonic dot net

This one will result in the same corrupt phar archive:
$phar = new Phar("test.phar");
$iterator = new RecursiveIteratorIterator(new 
RecursiveDirectoryIterator("/tmp/test/content", FilesystemIterator::SKIP_DOTS));
$phar->buildFromIterator($iterator, "/tmp/test/content");
$phar->compress(Phar::GZ);




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=65028


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

Bug #65028 [Opn]: Phar::buildFromDirectory creates corrupt archives for some specific contents

[stas]

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

 ID: 65028
 Updated by: s...@php.net
 Reported by:matthias dot burtscher at fusonic dot net
 Summary:Phar::buildFromDirectory creates corrupt archives
 for some specific contents
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   Ubuntu 13.04, Windows 7
 PHP Version:5.3.x, 5.4.x, 5.5.x
 Block user comment: N
 Private report: N

 New Comment:

Matthias, please check if https://github.com/php/php-src/pull/392 fixes your 
problem?


Previous Comments:

[2013-07-22 07:27:49] s...@php.net

This is a funny one. Seems to be because phar writes the archive this way:

METADATA_HEADER

Where METADATA_HEADER contains phar metadata, first 4 bytes being metadata 
length. However, when phar reads the file, it checks if "__HALT_COMPILER(); ?>" 
is followed by \r, and if there's \r it also looks for \n. Now imagine what 
happens if metadata length is such that its first byte is 0x0D, but second byte 
is not 0x0A? Phar file is not readable anymore.


[2013-06-28 05:59:09] matthias dot burtscher at fusonic dot net

I managed to recreate the issue and submitted a test case right here on GitHub:
https://github.com/php/php-src/pull/371


[2013-06-27 11:59:34] matthias dot burtscher at fusonic dot net

Re-tested with the latest PHP 5.5.0 release, still not working.


[2013-06-13 14:10:01] matthias dot burtscher at fusonic dot net

This one will result in the same corrupt phar archive:
$phar = new Phar("test.phar");
$iterator = new RecursiveIteratorIterator(new 
RecursiveDirectoryIterator("/tmp/test/content", FilesystemIterator::SKIP_DOTS));
$phar->buildFromIterator($iterator, "/tmp/test/content");
$phar->compress(Phar::GZ);


[2013-06-13 11:47:12] matthias dot burtscher at fusonic dot net

Description:

When creating a Phar archive with a very simple Phar::createFromDirectory() 
call 
(see test script) the generated archive is corrupt sometimes, depending on the 
contents packed into the Phar.

I CAN PROVIDE THE TEST CONTENTS TO A DEVELOPER BUT NOT TO THE PUBLIC.

Opening the Phar will cause a Fatal error. Adding an additional empty file (see 
test script) to the archive fixes the problem. Sometimes a second empty file 
has 
to be added, sometimes a third one.

Tested PHP versions:
- 5.3.26
- 5.4.16
- 5.5.0 RC3

Configure line (all versions):
'./configure'  
'--prefix=/opt/php/bin/php-5.3.26' 
'--with-gd' 
'--with-ldap=/usr' 
'--with-mysql' 
'--with-mssql' 
'--with-pdo-mysql' 
'--with-pdo-dblib' 
'--with-pdo-pgsql' 
'--with-pgsql' 
'--with-config-file-path=/opt/php/bin/php-5.3.26/etc' 
'--enable-mbstring' 
'--with-mcrypt' 
'--with-openssl' 
'--with-curl'
'--with-zlib' 
'--with-libdir=lib/x86_64-linux-gnu' 
'--with-jpeg-dir' 
'--with-png-dir'

Test script:
---
// Corrupt
$phar = new Phar("test.phar");
$phar->buildFromDirectory("content");
$phar->compress(Phar::GZ);

// Working (only difference is adding the empty file)
$phar = new Phar("test.phar");
$phar->buildFromDirectory("content");
$phar->addFromString("an-empty-file", "");
$phar->compress(Phar::GZ);

Expected result:

Working phar archive which can be opened with "new Phar('test.phar')".

Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message 
'internal 
corruption of phar "/tmp/test/test.phar" (truncated manifest at stub end)'






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

Bug #65028 [Opn]: Phar::buildFromDirectory creates corrupt archives for some specific contents

[stas]

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

 ID: 65028
 Updated by: s...@php.net
 Reported by:matthias dot burtscher at fusonic dot net
 Summary:Phar::buildFromDirectory creates corrupt archives
 for some specific contents
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   Ubuntu 13.04, Windows 7
 PHP Version:5.3.x, 5.4.x, 5.5.x
 Block user comment: N
 Private report: N

 New Comment:

This is a funny one. Seems to be because phar writes the archive this way:

METADATA_HEADER

Where METADATA_HEADER contains phar metadata, first 4 bytes being metadata 
length. However, when phar reads the file, it checks if "__HALT_COMPILER(); ?>" 
is followed by \r, and if there's \r it also looks for \n. Now imagine what 
happens if metadata length is such that its first byte is 0x0D, but second byte 
is not 0x0A? Phar file is not readable anymore.


Previous Comments:

[2013-06-28 05:59:09] matthias dot burtscher at fusonic dot net

I managed to recreate the issue and submitted a test case right here on GitHub:
https://github.com/php/php-src/pull/371


[2013-06-27 11:59:34] matthias dot burtscher at fusonic dot net

Re-tested with the latest PHP 5.5.0 release, still not working.


[2013-06-13 14:10:01] matthias dot burtscher at fusonic dot net

This one will result in the same corrupt phar archive:
$phar = new Phar("test.phar");
$iterator = new RecursiveIteratorIterator(new 
RecursiveDirectoryIterator("/tmp/test/content", FilesystemIterator::SKIP_DOTS));
$phar->buildFromIterator($iterator, "/tmp/test/content");
$phar->compress(Phar::GZ);


[2013-06-13 11:47:12] matthias dot burtscher at fusonic dot net

Description:

When creating a Phar archive with a very simple Phar::createFromDirectory() 
call 
(see test script) the generated archive is corrupt sometimes, depending on the 
contents packed into the Phar.

I CAN PROVIDE THE TEST CONTENTS TO A DEVELOPER BUT NOT TO THE PUBLIC.

Opening the Phar will cause a Fatal error. Adding an additional empty file (see 
test script) to the archive fixes the problem. Sometimes a second empty file 
has 
to be added, sometimes a third one.

Tested PHP versions:
- 5.3.26
- 5.4.16
- 5.5.0 RC3

Configure line (all versions):
'./configure'  
'--prefix=/opt/php/bin/php-5.3.26' 
'--with-gd' 
'--with-ldap=/usr' 
'--with-mysql' 
'--with-mssql' 
'--with-pdo-mysql' 
'--with-pdo-dblib' 
'--with-pdo-pgsql' 
'--with-pgsql' 
'--with-config-file-path=/opt/php/bin/php-5.3.26/etc' 
'--enable-mbstring' 
'--with-mcrypt' 
'--with-openssl' 
'--with-curl'
'--with-zlib' 
'--with-libdir=lib/x86_64-linux-gnu' 
'--with-jpeg-dir' 
'--with-png-dir'

Test script:
---
// Corrupt
$phar = new Phar("test.phar");
$phar->buildFromDirectory("content");
$phar->compress(Phar::GZ);

// Working (only difference is adding the empty file)
$phar = new Phar("test.phar");
$phar->buildFromDirectory("content");
$phar->addFromString("an-empty-file", "");
$phar->compress(Phar::GZ);

Expected result:

Working phar archive which can be opened with "new Phar('test.phar')".

Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message 
'internal 
corruption of phar "/tmp/test/test.phar" (truncated manifest at stub end)'






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

Bug #61697 [Asn->Csd]: spl_autoload_functions returns lambda functions incorrectly

[stas]

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

 ID: 61697
 Updated by: s...@php.net
 Reported by:stadli at gmx dot de
 Summary:spl_autoload_functions returns lambda functions
 incorrectly
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SPL related
 PHP Version:5.4.0
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=83ced9124ea0f7be4950b8267b518b05c70323fe
Log: Fix bug #61697 - spl_autoload_functions returns lambda functions 
incorrectly


Previous Comments:

[2013-06-25 05:18:59] larue...@php.net

hmm, thanks for the reminding, I'd like to see this could happen in 5.5

@dsp, what do you think?


[2013-06-24 18:12:05] fel...@php.net

David, what about this change on 5.5?


[2013-03-11 04:09:41] stadli at gmx dot de

Is there a reason, why this fix still hasn't been implemented?

I'd like to see this bug fixed in PHP 5.5


[2012-04-12 05:21:32] larue...@php.net

I have made a patch for this, but there is a BC break, that is, 
spl_autoload_functions return lambad_function with name "__lambad_function" 
previously.

after patched, it will return string like "lambad_1".


[2012-04-12 05:19:39] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61697.phpt
Revision:   1334207979
URL:
https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.phpt&revision=1334207979




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=61697


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

Bug #62479 [Ver]: PDO-psql cannot connect if password contains spaces

[stas]

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

 ID: 62479
 Updated by: s...@php.net
 Reported by:brice at bmaron dot net
 Summary:PDO-psql cannot connect if password contains spaces
 Status: Verified
 Type:   Bug
 Package:PDO related
 Operating System:   Linux- Debian Stable
 PHP Version:5.3.14
 Assigned To:willfitch
 Block user comment: N
 Private report: N

 New Comment:

Will, any news on the updated patch?


Previous Comments:

[2012-10-31 18:47:05] willfi...@php.net

Thanks Iliaa -

I will update the pull request to take into account escaping backslashes as 
well.


[2012-10-31 01:53:20] il...@php.net

I think the attached patch maybe slightly better than the one proposed, the 
attached patch also accounts for passwords that may contain \ character inside 
them.


[2012-10-31 01:51:40] il...@php.net

The following patch has been added/updated:

Patch Name: PDOPostgreSQLPassword
Revision:   1351648300
URL:
https://bugs.php.net/patch-display.php?bug=62479&patch=PDOPostgreSQLPassword&revision=1351648300


[2012-09-20 20:12:00] willfi...@php.net

Pull request for this bug has been submitted at: https://github.com/php/php-
src/pull/199.


[2012-09-17 19:39:08] willfi...@php.net

I have confirmed your findings. Let me do a little sniffing around and see what 
I 
can come up with.




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=62479


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

Bug #62665 [Opn->Csd]: curl.cainfo doesn't appear in php.ini

[stas]

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

 ID: 62665
 Updated by: s...@php.net
 Reported by:lior dot k at zend dot com
 Summary:curl.cainfo doesn't appear in php.ini
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHP options/info functions
 PHP Version:5.3.15
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2bad01e61ba2677e1e8303f9b56574ebb7ba3f00
Log: Fix bug #62665: add curl.cainfo to php.ini


Previous Comments:

[2012-07-26 08:41:49] lior dot k at zend dot com

Description:

The curl.cainfo run time option was added in PHP 5.3.7 (see 
http://www.php.net/manual/en/curl.configuration.php) but it wasn't added to 
php.ini

Please add it.







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

Bug #52062 [Asn->Csd]: large timestamps with DateTime::getTimestamp and DateTime::setTimestamp

[stas]

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

 ID: 52062
 Updated by: s...@php.net
 Reported by:dan at bnet dot lt
 Summary:large timestamps with DateTime::getTimestamp and
 DateTime::setTimestamp
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Ubuntu i686 2.6.32-22-generic
 PHP Version:5.4.0RC4
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

Works for me in 5.4 on both 32-bit and 64-bit, so looks like it's fixed.


Previous Comments:

[2013-04-14 16:23:34] pbxanime at gmail dot com

Related To: Bug #64606


[2012-08-13 17:21:43] ni...@php.net

This test currently passes for me (I get a warning for a passing xfail test). 
So is this fixed? Or depending on OS or something?


[2012-07-24 23:38:15] ras...@php.net

Automatic comment on behalf of derick
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b2b7d5b94314e34f9b2a69e1b7e25aa7dd3e4a5c
Log: - Fixed bug #52062: large timestamps with DateTime::getTimestamp and 
DateTime::setTimestamp.


[2012-07-24 23:38:12] ras...@php.net

Automatic comment on behalf of derick
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=4c9fad8b362a7d2b6a94b4961e4b2dc037b2766d
Log: - Fixed bug #53502 (strtotime with timezone memory leak). - Fixed bug 
#52062 (large timestamps with DateTime::getTimestamp and   
DateTime::setTimestamp). - Fixed bug #51994 (date_parse_from_format is parsing 
invalid date using 'yz'   format). - Fixed bug #51223 (Seg fault while creating 
(by unserialization)   DatePeriod).


[2012-07-24 23:36:15] ras...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=7a2a75d0570e685e3d644e3e4931b92463ef9eb0
Log: Fix bug #61609 Test ext\date\tests\bug52062.phpt fails As expressed in the 
comments http://de.php.net/manual/en/datetime.gettimestamp.php this is the 
generic 32 bit timestamp 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=52062


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

Bug #62759 [Opn->Csd]: Buggy grapheme_substr() on edge case

[stas]

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

 ID: 62759
 Updated by: s...@php.net
 Reported by:okin7 at yahoo dot fr
 Summary:Buggy grapheme_substr() on edge case
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*Languages/Translation
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=860a5c4b01cd63588ed2eaae76cf0243ca8c3173
Log: Fix bug #62759: Buggy grapheme_substr() on edge case


Previous Comments:

[2012-08-06 16:05:52] okin7 at yahoo dot fr

Description:

See test script below.

The strangest behavior is the difference between a pure ASCII string and an 
UTF-8 with chars in the [80-] range.

The other wrong thing is the difference of behavior between substr() and 
grapheme_substr(). I think substr's behavior is the good one.

Test script:
---



Expected result:

bool(false)
string(0) ""
bool(false)
string(0) ""
bool(false)
string(0) ""


Actual result:
--
bool(false)
string(0) ""
bool(false)
string(0) ""
string(5) "éjà"
bool(false)







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

Req #63472 [Csd]: Not possibe to set SO_BINDTODEVICE with socket_set_option

[stas]

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

 ID: 63472
 Updated by: s...@php.net
 Reported by:zobo at scene-si dot org
 Summary:Not possibe to set SO_BINDTODEVICE with
 socket_set_option
 Status: Closed
 Type:   Feature/Change Request
 Package:Sockets related
 Operating System:   Linux
 PHP Version:master-Git-2012-11-09 (Git)
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

merged as a0b4348abc09e00170a334c6f67ef399e8b36a1e


Previous Comments:

[2013-06-23 22:31:33] s...@php.net

The fix for this bug has been committed.

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.




[2012-11-09 15:13:08] zobo at scene-si dot org

Description:

In network/socket programming in Linux there are situations when one needs to 
bind the socket to a specific interface. This is especially important when 
dealaing with broadcasts. Linux has SO_BINDTODEVICE to do this.
But currently it is impossible to use this option with PHP as any unknown 
options value will get translated to long and only then passed to setsockopt.

There are two ways to address this issue.

Change the default handler so, that if the argument is string, this is actually 
passed to setsockopt. This not only solves this issue, but also opens 
impossibles for future options with funky format where pack() may be abused to 
get them working without changes to the extension code.

But as this might break BC, there are two other approaches:
1. Just add a case statement specifically for SO_BINDTODEVICE
2. Add some sort of flag to the function parameters (either a bit in the 
options 
argument, or something else) that requests this special "raw" processing of the 
argument value.

It would make sense to have the socket_get_option counterpart also implemented. 
Not provided in the patch.








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

Req #63472 [Opn->Csd]: Not possibe to set SO_BINDTODEVICE with socket_set_option

[stas]

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

 ID: 63472
 Updated by: s...@php.net
 Reported by:zobo at scene-si dot org
 Summary:Not possibe to set SO_BINDTODEVICE with
 socket_set_option
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Sockets related
 Operating System:   Linux
 PHP Version:master-Git-2012-11-09 (Git)
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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-11-09 15:13:08] zobo at scene-si dot org

Description:

In network/socket programming in Linux there are situations when one needs to 
bind the socket to a specific interface. This is especially important when 
dealaing with broadcasts. Linux has SO_BINDTODEVICE to do this.
But currently it is impossible to use this option with PHP as any unknown 
options value will get translated to long and only then passed to setsockopt.

There are two ways to address this issue.

Change the default handler so, that if the argument is string, this is actually 
passed to setsockopt. This not only solves this issue, but also opens 
impossibles for future options with funky format where pack() may be abused to 
get them working without changes to the extension code.

But as this might break BC, there are two other approaches:
1. Just add a case statement specifically for SO_BINDTODEVICE
2. Add some sort of flag to the function parameters (either a bit in the 
options 
argument, or something else) that requests this special "raw" processing of the 
argument value.

It would make sense to have the socket_get_option counterpart also implemented. 
Not provided in the patch.








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

Bug #48724 [Asn->Csd]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR

[stas]

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

 ID: 48724
 Updated by: s...@php.net
 Reported by:an0nym at narod dot ru
 Summary:getColumnMeta() doesn't return native_type for BIT,
 TINYINT and YEAR
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   *
 PHP Version:5.3.0
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of t...@daylessday.org
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=95cc763a1484c4922f6577c10de937299dc8c8e0
Log: fix bug #48724


Previous Comments:

[2012-04-16 12:12:38] tony2...@php.net

Ulf, could you pls check if the attached patch is correct?
Thanks.


[2012-04-13 12:06:15] tony2...@php.net

The following patch has been added/updated:

Patch Name: fix-bug-48724.patch
Revision:   1334318775
URL:
https://bugs.php.net/patch-display.php?bug=48724&patch=fix-bug-48724.patch&revision=1334318775


[2009-07-03 16:57:28] u...@php.net

You are free to patch it. 

Bye.


[2009-07-03 16:30:12] an0nym at narod dot ru

Poor MySQLi developers... they've managed to solve this problem without 
specification. 

Poor you... you've spent sooo many time for nothing developing this 
function, which works in 35 of 38 cases - this stuff has no 
specification! Wait for a specification - you have a good excuse! 

Bye.


[2009-07-03 16:17:20] u...@php.net

You are free to write a patch. 

I refuse to work on stuff that has no specification and which may go into any 
direction. That typically ends up in a backwards compatibility nightmare, which 
in particular for an abstraction like PDO makes no sense to me.

The patch may be rather simple. But watch out for different values returned by 
different MySQL versions.




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=48724


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

Req #55694 [Opn->Csd]: Expose additionnal readline variable to prevent default filename completion

[stas]

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

 ID: 55694
 Updated by: s...@php.net
 Reported by:axel dot ml at laposte dot net
 Summary:Expose additionnal readline variable to prevent
 default filename completion
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Readline related
 PHP Version:5.3.8
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

Pull merged into 5.4 and above.


Previous Comments:

[2011-09-14 14:42:42] axel dot ml at laposte dot net

Description:

Actually, when using a custom completion function with 
readline_completion_function(), if this custom completion function does not 
find any match, it falls back to the default filename completion.

In order to prevent this behaviour, the C API of readline provides a variable 
named "rl_attempted_completion_over". Defining this variable to a non-zero 
value disables the uses of the default filename completion.

This variable is not exposed to PHP and the filename completion cannot be 
bypassed. The provided patch exposes this variable to PHP, and allows to use 
readline_info("attempted_completion_over", 1) in the PHP completion function to 
prevent default filename completion to occurs.

There is a bug report but it s closed since 2005 
https://bugs.php.net/bug.php?id=31796

Another bug report for this https://bugs.php.net/bug.php?id=48089 with a patch 
which does the job but in a wrong way, imo.







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

Req #64764 [Asn->Csd]: add support for FPM init.d script

[stas]

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

 ID: 64764
 Updated by: s...@php.net
 Reported by:lior dot k at zend dot com
 Summary:add support for FPM init.d script
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:FPM related
 PHP Version:5.4.14
 Assigned To:tony2001
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of kaplanl...@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=ee01af7df149da2c511b0f91db2e161eebb2bf58
Log: Fix bug #64764: Add status option to fpm init.d script


Previous Comments:

[2013-05-30 13:53:17] dmi...@php.net

Tony, please take a look. I don't see any problems with the patch.


[2013-05-02 17:53:48] lior dot k at zend dot com

Description:

The attached patch adds that status option to init.d.php-fpm.in file.







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

Bug #64247 [Opn->Fbk]: CURLOPT_INFILE doesn't allow reset for FTP

[stas]

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

 ID: 64247
 Updated by: s...@php.net
 Reported by:marco at m-s-d dot eu
 Summary:CURLOPT_INFILE doesn't allow reset for FTP
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:cURL related
 Operating System:   Linux 3.0.0-1-amd64 #1 SMP
 PHP Version:master-Git-2013-02-19 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Please add a test to the patch.


Previous Comments:

[2013-02-19 20:43:38] marco at m-s-d dot eu

Description:

When trying to do a PUT request using CURLOPT_INFILE followed by a GET, then 
the 
GET will encounter a "Warning: curl_setopt_array(): supplied argument is not a 
valid File-Handle resource" if the file handle has been closed.

This is a bug because you're supposed to free handles when you're not using 
them.

Setting NULL like with CURLOPT_HEADERFUNCTION (see 
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTHEADERFUNCTION) does 
not work, it gives "Warning: curl_setopt_array(): supplied argument is not a 
valid 
File-Handle resource".

See also Bug #44866 - leaking FDs is bad, bad program practice.

Test script:
---
http://pastebin.com/XLJsZ9JH - line 44 is the CURLOPT_INFILE=>NULL line.

Expected result:

Once CURLOPT_INFILE=>NULL has been set, I expect that the action of setting 
CURLOPT_INFILE=>$fp has been reversed (i.e. that curl has been reset to 
default),







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

Bug #64166 [Opn->Csd]: quoted-printable-encode stream filter incorrectly discarding whitespace

[stas]

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

 ID: 64166
 Updated by: s...@php.net
 Reported by:slusarz at curecanti dot org
 Summary:quoted-printable-encode stream filter incorrectly
 discarding whitespace
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   Linux
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of slus...@curecanti.org
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b5b0a53b09776f74ab4ddf6b9468ab1b41267ab5
Log: Fix #64166: quoted-printable-encode stream filter incorrectly discarding 
whitespace


Previous Comments:

[2013-02-25 02:28:22] slusarz at curecanti dot org

Updated pull request with new commit that should take care of all concerns.  
Also implemented a more complete unit test.


[2013-02-17 09:13:59] s...@php.net

The patch seems to have problems with split writes, see my comments there.


[2013-02-07 19:41:22] slusarz at curecanti dot org

Added pull request with fix that seems to work (w/unit test):

https://github.com/php/php-src/pull/272


[2013-02-07 01:14:58] slusarz at curecanti dot org

Just kidding... apparently there's a difference between "filter" and "stream 
filter".  Sorry for the noise.


[2013-02-07 01:14:09] slusarz at curecanti dot org

This is actually a stream *filter* issue, so put in filter queue.




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=64166


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

Bug #64936 [Opn->Csd]: doc comments picked up from previous scanner run

[stas]

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

 ID: 64936
 Updated by: s...@php.net
 Reported by:jonathan at moo dot com
 Summary:doc comments picked up from previous scanner run
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reflection related
 PHP Version:master-Git-2013-05-28 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=2208447d428542960c73cfeceaf52e95ff0ca2d0
Log: Fix bug #64936 - clean doc comment state at the beginning and end of the 
scan


Previous Comments:

[2013-05-28 12:58:19] jonathan at moo dot com

Description:

The doc_comment compiler global is not reset when scanning of a new file/string 
starts. This leads to the last doc_comment seen by the tokenizer, but unclaimed 
by anything, being incorrectly assigned to the next thing the compiler sees.

I think that the doc_comment and doc_comment_len globals should probably be 
saved/restored by zend_(save|restore)_lexical_state, and reset whenever 
scanning 
for a new file or string starts (pretty much everywhere zend_lineno gets 
initialised.)

Test script:
---
token_get_all("getDocComment()); // Foo shouldn't have a doc comment, and yet it 
does.

Expected result:

bool(false)

Actual result:
--
string(14) "/**\n * Foo\n */"






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

Bug #62649 [Opn->Csd]: phar.phar.bat missing quotes

[stas]

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

 ID: 62649
 Updated by: s...@php.net
 Reported by:mlocati at gmail dot com
 Summary:phar.phar.bat missing quotes
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHAR related
 Operating System:   Windows 7 64 bit
 PHP Version:5.3.15
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

Looks like dsp already merged it.


Previous Comments:

[2012-07-24 08:53:58] mlocati at gmail dot com

Description:

phar.phar.bat is missing double quotes:
instead of
%~dp0php.exe %~dp0pharcommand.phar %*
we should have
"%~dp0php.exe" "%~dp0pharcommand.phar" %*







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

Bug #60953 [Asn->Fbk]: Bug adding file extension using convertToExecutable()

[stas]

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

 ID: 60953
 Updated by: s...@php.net
 Reported by:trq at proemframework dot org
 Summary:Bug adding file extension using
 convertToExecutable()
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:PHAR related
 Operating System:   Linux dev 2.6.32-042stab016.1 #1
 PHP Version:5.4.0RC6
 Assigned To:ralphschindler
 Block user comment: N
 Private report: N

 New Comment:

Please see some notes in the patch.


Previous Comments:

[2012-02-02 13:05:30] trq at proemframework dot org

Description:

When using convertToExecutable() to add compression to an existing phar 
archive, 
if the original phar name contains full stops . the new phar.tar.gz extension 
is 
added to early.

eg;

proem-0.1.2.phar

becomes:

proem-0.phar.tar.gz

Test script:
---
#!/usr/bin/env php
buildFromDirectory('lib');
$phar->setStub("registerNamespaces(['Proem' => 'lib'])->register();
__HALT_COMPILER();
?>");
$phar->convertToExecutable(Phar::TAR, Phar::GZ);

Expected result:

thorpe@dev[~/src/proem][master]+ ls -l build/
total 76
-rw-r--r-- 1 thorpe thorpe 64006 Feb  2 23:53 proem-0.1.2.phar
-rw-r--r-- 1 thorpe thorpe  8523 Feb  2 23:53 proem-0.1.2.phar.tar.gz

Actual result:
--
thorpe@dev[~/src/proem][master]+ ls -l build/
total 76
-rw-r--r-- 1 thorpe thorpe 64006 Feb  2 23:53 proem-0.1.2.phar
-rw-r--r-- 1 thorpe thorpe  8523 Feb  2 23:53 proem-0.phar.tar.gz






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

Sec Bug->Bug #65000 [Opn]: use after free (double free) caused by emalloc in _zval_copy_ctor_func

[stas]

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

 ID: 65000
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:use after free (double free) caused by emalloc in
 _zval_copy_ctor_func
 Status: Open
-Type:   Security
+Type:   Bug
-Package:*General Issues
+Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.16
 Block user comment: N
 Private report: Y



Previous Comments:

[2013-06-09 16:05:18] s...@php.net

Description:

$ ./php --version
PHP 5.4.16 (cli) (built: Jun  9 2013 17:56:24) (DEBUG)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
---
(gdb) r ~shm/php1.php 
Starting program: /home/fuzzphp/php-5.4.16/sapi/cli/php ~shm/php1.php

Fatal error: Allowed memory size of 33554432 bytes exhausted at 
/home/fuzzphp/php-5.4.16/Zend/zend_vm_execute.h:27134 (tried to allocate 
3001 bytes) in /home/shm/php1.php on line 11

Program received signal SIGSEGV, Segmentation fault.
0x008ebc07 in _zval_dtor_func (zvalue=0x77fdb4d8, 
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c", 
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.c:35
35  CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0  0x008ebc07 in _zval_dtor_func (zvalue=0x77fdb4d8, 
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c", 
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.c:35
#1  0x008da584 in _zval_dtor (zvalue=0x77fdb4d8, 
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c", 
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.h:35
#2  0x008db528 in _zval_ptr_dtor (zval_ptr=0x77fdcb00, 
__zend_filename=0xeae170 "/home/fuzzphp/php-5.4.16/Zend/zend_variables.c", 
__zend_lineno=182)
at /home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c:438
#3  0x008ec0c1 in _zval_ptr_dtor_wrapper (zval_ptr=0x77fdcb00) at 
/home/fuzzphp/php-5.4.16/Zend/zend_variables.c:182
#4  0x0090046a in zend_hash_apply_deleter (ht=0x116ad88, 
p=0x77fdcae8) at /home/fuzzphp/php-5.4.16/Zend/zend_hash.c:650
#5  0x009005fb in zend_hash_graceful_reverse_destroy (ht=0x116ad88) at 
/home/fuzzphp/php-5.4.16/Zend/zend_hash.c:687
#6  0x008daed3 in shutdown_executor () at 
/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c:247
#7  0x008edf1e in zend_deactivate () at 
/home/fuzzphp/php-5.4.16/Zend/zend.c:938
#8  0x0086438f in php_request_shutdown (dummy=0x0) at 
/home/fuzzphp/php-5.4.16/main/main.c:1800
#9  0x00990d12 in do_cli (argc=2, argv=0x7fffe628) at 
/home/fuzzphp/php-5.4.16/sapi/cli/php_cli.c:1171
#10 0x00991418 in main (argc=2, argv=0x7fffe628) at 
/home/fuzzphp/php-5.4.16/sapi/cli/php_cli.c:1364
-

It seems that _zval_copy_ctor_func can be used to trigger double free/use after 
free issue, in case when emalloc pointed here: 
http://lxr.php.net/xref/PHP_5_4/Zend/zend_variables.c#123 fails (estrndup calls 
emalloc internally). The interpreter runs destroy functions on error (memory 
exhastion) which lead to use value.str.val two times. Please see the test 
script for details.

I'm not sure how to fix the issue, so I left it for smarter than me. :-)


Test script:
---
https://bugs.php.net/bug.php?id=65000&edit=1

Bug #64910 [Opn]: Line number of $e = new Exception vs. line number of throw $e

[stas]

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

 ID: 64910
 Updated by: s...@php.net
 Reported by:sebast...@php.net
 Summary:Line number of $e = new Exception vs. line number of
 throw $e
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:5.5Git-2013-05-23 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Consider however this:

try {
//stuff
} catch(Exception $e) {
$logger->log("Oops, exception!");
throw $e;
}

If we update file/line here, we lose original exception information and
file/line in the exception becomes useless. Right now, since 99.99% of
the code does "throw new", it is always useful. 

So how would you propose to solve this?


Previous Comments:

[2013-05-23 17:20:49] der...@php.net

I'd agree with this. Seems like a fix could be to update the file and line 
properties of the exception in 
zend_throw_exception_internal/zend_throw_exception. Right now, it's set in the 
object init of the Exception class only.


[2013-05-23 16:07:15] sebast...@php.net

Description:

The error message that is created for an uncaught exception as well as the 
stacktrace of an exception list the number of the line on which the exception 
object was created. I would expect this to be number of the line on which the 
exception is raised using the throw statement.

Also note that the documentation on this is inconsistent: the 
Exception::getLine() method is documented with "Gets the line in which the 
exception occurred" whereas the Exception::$line attribute is documented with 
"The line where the exception was created".

Test script:
---
https://bugs.php.net/bug.php?id=64910&edit=1

Sec Bug->Bug #64911 [Opn]: Looped forward_static_call causes segfault

[stas]

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

 ID: 64911
 Updated by: s...@php.net
 Reported by:jutaky at ee dot oulu dot fi
 Summary:Looped forward_static_call causes segfault
 Status: Open
-Type:   Security
+Type:   Bug
 Package:Reproducible crash
 Operating System:   ArchLinux
 PHP Version:5.4.15
 Block user comment: N
 Private report: Y

 New Comment:

Does not seem to be a security issue.


Previous Comments:

[2013-05-23 17:13:45] jutaky at ee dot oulu dot fi

Description:

Looped forward_static_call causes segfault on PHP 5.4.15, 5.5.0RC2 and on trunk 
(20130523).

Configure for PHP 5.5.0RC2 and trunk: ./configure --enable-debug

Worth noting: xdebug extension prevented crash and exited PHP cleanly.

Backtrace is extremely long, here are ten first entries:

#0  0x007896d1 in _zend_mm_alloc_int (heap=, 
size=, __zend_filename=, 
__zend_lineno=, 
__zend_orig_filename=, 
__zend_orig_lineno=)
at /Zend/zend_alloc.c:1881
#1  0x0078b3f3 in _emalloc (size=4, __zend_filename=0xbd7e38 "
/Zend/zend_operators.c", 
__zend_lineno=1979, 
__zend_orig_filename=0x0, __zend_orig_lineno=0) at 
/Zend/zend_alloc.c:2429
#2  0x007bec56 in zend_str_tolower_dup (source=0x77e95ac0 
"foo::bar", length=3) at 
/Zend/zend_operators.c:1979
#3  0x007ce357 in zend_is_callable_check_class (name=0x77e95ac0 
"foo::bar", name_len=3, 
fcc=0x7f7ff720, strict_class=0x7f7ff168, error=0x7f7ff368)
at /Zend/zend_API.c:2673
#4  0x007cea6e in zend_is_callable_check_func (check_flags=0, 
callable=0x75b4dbc8, 
fcc=0x7f7ff720, strict_class=0, error=0x7f7ff368)
at /Zend/zend_API.c:2795
#5  0x007cfc75 in zend_is_callable_ex (callable=0x75b4dbc8, 
object_ptr=0x0, check_flags=0, 
callable_name=0x0, callable_name_len=0x7f7ff294, 
fcc=0x7f7ff720, error=0x7f7ff368) at /Zend/zend_API.c:3059
#6  0x007d0710 in zend_fcall_info_init (callable=0x75b4dbc8, 
check_flags=0, fci=0x7f7ff750, 
fcc=0x7f7ff720, callable_name=0x0, error=0x7f7ff368)
at /Zend/zend_API.c:3235
#7  0x007c6d89 in zend_parse_arg_impl (arg_num=1, arg=0x75bab758, 
va=0x7f7ff610, 
spec=0x7f7ff540, error=0x7f7ff4e8, severity=0x7f7ff4e4)
at /Zend/zend_API.c:632
#8  0x007c7061 in zend_parse_arg (arg_num=1, arg=0x75bab758, 
va=0x7f7ff610, 
spec=0x7f7ff540, quiet=0)
at /Zend/zend_API.c:691
#9  0x007c787c in zend_parse_va_args (num_args=0, type_spec=0xbaabcb 
"f*", va=0x7f7ff610, flags=0)
at /Zend/zend_API.c:873
#10 0x007c7b4f in zend_parse_parameters (num_args=1, type_spec=0xbaabcb 
"f*") at 
/Zend/zend_API.c:924


Test script:
---
Example case: http://jutaky.com/fuzzing/loopz.html

Expected result:

Possibly looping until killed, reaching max_execution_time or other PHP set 
limit 
is reached?

Actual result:
--
Segmentation fault.






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

Bug #63159 [NoF->Opn]: Passing > 1 additional module to php_module_startup causes a segfault

[stas]

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

 ID: 63159
 Updated by: s...@php.net
 Reported by:slangley at google dot com
 Summary:Passing > 1 additional module to php_module_startup
 causes a segfault
-Status: No Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   N/A
 PHP Version:5.4.7
 Block user comment: N
 Private report: N



Previous Comments:

[2013-02-18 00:36:02] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


[2013-01-28 10:46:47] slangley at google dot com

Well according to this I'm not :) 

http://marc.info/?l=php-internals&m=110121150631159&w=2


[2013-01-28 10:44:00] paj...@php.net

oh, stupid me, coffee++ :-)

You must be the 1st to call it with more than one ;-)


[2013-01-28 10:35:00] slangley at google dot com

I'll grab you a stack trace when I'm in to office tomorrow (need to remove my 
patch to get it to crash :)) However you can pretty easily walk through the 
code.

int php_module_startup(sapi_module_struct *sf, zend_module_entry 
*additional_modules, uint num_additional_modules)

Takes a pointer to an array of zend_module_entry.

int php_register_extensions(zend_module_entry **ptr, int count TSRMLS_DC)


takes a pointer to an array of zend_module_entry pointers.

inside php_register_extensions it uses pointer arithmetic to enumerate the 
extensions. However, because php_module_startup has a pointer to an array of 
zend_module_entry rather than a pointer to an array of pointers of 
zend_module_entry it causes a segfault.

https://github.com/php/php-src/blob/master/main/main.c#L1961

https://github.com/php/php-src/blob/master/main/main.c#L1909


[2013-01-28 10:28:53] paj...@php.net

http://lxr.php.net/xref/PHP_5_4/main/main.c#1910 looks perfectly fine to me.

Which value do you actually pass as count? Also provide a backtrace.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

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


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

Sec Bug->Req #53495 [Opn]: PHP should fail if executed as superuser and php.ini is world-writeable

[stas]

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

 ID: 53495
 Updated by: s...@php.net
 Reported by:marcel dot esser at gmail dot com
 Summary:PHP should fail if executed as superuser and php.ini
 is world-writeable
 Status: Open
-Type:   Security
+Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   UNIX-like
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N



Previous Comments:

[2011-03-19 01:54:24] geiss...@php.net

Personal opinion follows:

a) If such a check was to be included, there's no reason to special case it to 
root. Arbitrary code execution under whatever user is an issue.

b) There are plenty of other ways to escalate privileges if files are world-
writeable. Only checking for php.ini's perms would give a false sense for 
security, while checking for every single file read by php would be paranoid 
and 
a waste of time.

There's an easier fix: don't make files world-writeable.

(I don't see anything in this report that requires it to be private, so I'm 
removing the flag.)


[2010-12-08 02:00:07] marcel dot esser at gmail dot com

Description:

PHP should fail if executed as root, and if the currently used php.ini is world 
writable.

If php.ini is left world-writable, an attacker can auto-pretend or auto-append 
malicious code to execute when a script is invoked as root.

Test script:
---
marcel@kekeke:~$ sudo php test.php
I am executing as root!
hello

marcel@kekeke:~$ cat /etc/php5/php.ini | grep -i auto_prepend
auto_prepend_file = /tmp/malice.php

marcel@kekeke:~$ ls -lah /tmp/malice.php 
-rw-r--r-- 1 marcel marcel 40 Dec  8 00:58 /tmp/malice.php

marcel@kekeke:~$ ls -lah /etc/php5/php.ini 
-rw-rw-rw- 1 root root 67K Dec  8 00:57 /etc/php5/php.ini

marcel@kekeke:~$ cat test.php
https://bugs.php.net/bug.php?id=53495&edit=1

Sec Bug->Bug #64509 [Opn->Nab]: 404 page

[stas]

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

 ID: 64509
 Updated by: s...@php.net
 Reported by:scott dot kennedy at interdesignusa dot com
 Summary:404 page
-Status: Open
+Status: Not a bug
-Type:   Security
+Type:   Bug
 Package:*Web Server problem
 Operating System:   Irrelevany
 PHP Version:Irrelevant
 Block user comment: N
 Private report: Y

 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.




Previous Comments:

[2013-03-25 13:01:36] scott dot kennedy at interdesignusa dot com

Description:

http://www.php.net/manual/en/language.oop5.patterns.php

Trying to view the page in English and keep getting a 404







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

Req #39694 [Opn->Nab]: transformToDoc() vs. transformToDocument()

[stas]

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

 ID: 39694
 Updated by: s...@php.net
 Reported by:lbzwischenbrugger at fh-stpoelten dot ac dot at
 Summary:transformToDoc() vs. transformToDocument()
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:XSLT related
 Operating System:   *
 PHP Version:5CVS-2006-11-30 (CVS)
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is released API, so changing it would be a BC issue.


Previous Comments:

[2006-11-30 15:47:17] lbzwischenbrugger at fh-stpoelten dot ac dot at

Description:

The method transformToDoc() should be called transformToDocument().



Reproduce code:
---
PHP Syntax:
---
http://at.php.net/xsl-xsltprocessor-transform-to-doc
$processor=new XSLTProcessor();
$processor->importStyleSheet($xsldomObject);
$result=$processor->transformToDoc($domObject);


Javascript Syntax:
--
http://developer.mozilla.org/en/docs/The_XSLT/JavaScript_Interface_in_Gecko:Interface_List
processor=new XSLTProcessor();
processor.importStyleSheet(xsldomObject);
result=processor.transformToDocument(domObject);








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

Bug #64433 [Fbk->Csd]: follow_location parameter of context is ignored for most response codes

[stas]

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

 ID: 64433
 Updated by: s...@php.net
 Reported by:akbarovs at gmail dot com
 Summary:follow_location parameter of context is ignored for
 most response codes
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   Any
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of sergey@terranova.(none)
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=1d4fcdff9f8a5b183cd99295f330bb92dbcf1105
Log: Fix bug #64433: does not follow redirects for non-3xx response codes


Previous Comments:

[2013-03-31 03:07:43] s...@php.net

Please explain the use case for such change - why we should be following 
redirects when no redirect actually exists, as given by the response.


[2013-03-15 17:04:35] akbarovs at gmail dot com

I've attached pull request for this issue:
https://github.com/php/php-src/pull/303


[2013-03-15 16:41:23] akbarovs at gmail dot com

Description:

Affected PHP versions: 5.4.12, 5.4.13, Git

The problem is that in new releases PHP ignores 'follow_location' context 
parameters for the response codes not in (300, 301, 302, 303 and 307). Problem 
is related to bugfix for bug #62524. Response codes should not be checked in 
the 
same condition where we check 'follow_location' parameter. And when we do that 
'follow_location' is always 1 for most response codes (ex.: 201): so we always 
redirect to the 'Location' and it cannot be changed using 'follow_location'=>0

You can see curl log for the sample resource where we combine 201 response code 
with 'Location' header: https://gist.github.com/akbarovs/5171115
For the test script I expect following response:
{"success": "ok"}

But when I execute it I get: {"documentId": 15} regardless to the 
follow_location parameter. I can remove it from the context parameter but I 
will 
continue receive wrong response.

I've attached patch for this issue. If 'follow_location' is not specified we do 
redirect for 3xx response codes. Otherwise we do not follow redirect. If 
'follow_location' is specified -> we do/do not follow redirects without 
checking 
response codes (if somebody really want to be redirected why we shouldn't allow 
to do it?)

BTW, I can send pull request via github if needed

Test script:
---

array(
'method'=>'POST',   
'follow_location'=>0,   
'content' => $requestXML

)
);
$context = stream_context_create($arr);
$f = fopen('http://localhost:8000', 'r', FALSE, $context);

echo stream_get_contents($f);
?>


Expected result:

Expected result:
{"success": "ok"}


Actual result:
--
Redirected to localhost:8000?q=1 and got {"documentId": 15}






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

Bug #64433 [Opn->Fbk]: follow_location parameter of context is ignored for most response codes

[stas]

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

 ID: 64433
 Updated by: s...@php.net
 Reported by:akbarovs at gmail dot com
 Summary:follow_location parameter of context is ignored for
 most response codes
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   Any
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

Please explain the use case for such change - why we should be following 
redirects when no redirect actually exists, as given by the response.


Previous Comments:

[2013-03-15 17:04:35] akbarovs at gmail dot com

I've attached pull request for this issue:
https://github.com/php/php-src/pull/303


[2013-03-15 16:41:23] akbarovs at gmail dot com

Description:

Affected PHP versions: 5.4.12, 5.4.13, Git

The problem is that in new releases PHP ignores 'follow_location' context 
parameters for the response codes not in (300, 301, 302, 303 and 307). Problem 
is related to bugfix for bug #62524. Response codes should not be checked in 
the 
same condition where we check 'follow_location' parameter. And when we do that 
'follow_location' is always 1 for most response codes (ex.: 201): so we always 
redirect to the 'Location' and it cannot be changed using 'follow_location'=>0

You can see curl log for the sample resource where we combine 201 response code 
with 'Location' header: https://gist.github.com/akbarovs/5171115
For the test script I expect following response:
{"success": "ok"}

But when I execute it I get: {"documentId": 15} regardless to the 
follow_location parameter. I can remove it from the context parameter but I 
will 
continue receive wrong response.

I've attached patch for this issue. If 'follow_location' is not specified we do 
redirect for 3xx response codes. Otherwise we do not follow redirect. If 
'follow_location' is specified -> we do/do not follow redirects without 
checking 
response codes (if somebody really want to be redirected why we shouldn't allow 
to do it?)

BTW, I can send pull request via github if needed

Test script:
---

array(
'method'=>'POST',   
'follow_location'=>0,   
'content' => $requestXML

)
);
$context = stream_context_create($arr);
$f = fopen('http://localhost:8000', 'r', FALSE, $context);

echo stream_get_contents($f);
?>


Expected result:

Expected result:
{"success": "ok"}


Actual result:
--
Redirected to localhost:8000?q=1 and got {"documentId": 15}






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

Bug #63914 [Opn]: zend_do_fcall_common_helper_SPEC does not handle exceptions properly

[stas]

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

 ID: 63914
 Updated by: s...@php.net
 Reported by:whatthejeff at gmail dot com
 Summary:zend_do_fcall_common_helper_SPEC does not handle
 exceptions properly
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   All
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Dmitry, could you review the proposed patch?


Previous Comments:

[2013-01-06 01:27:33] whatthejeff at gmail dot com

Pull request added: https://github.com/php/php-src/pull/250


[2013-01-06 00:35:00] whatthejeff at gmail dot com

Description:

The `zend_verify_arg_type` check in `zend_do_fcall_common_helper_SPEC` can 
generate unhanded exceptions when a user-defined error handler is set. This can 
lead to the following unexpected behaviors:

 * xdebug (and similar extensions using `execute_internal`) with PHP <= 5.4 
will 
segfault (http://bugs.xdebug.org/view.php?id=897)
 * xdebug (and similar extensions using `execute_internal`) with PHP 5.5+ will 
continue to execute the internal function in an inconsistant state.
 * PHP without xdebug-like extensions will continue to execute the internal 
function, even though it's unnecessary.

---

NOTE: I will send a pull request on github shortly.

Test script:
---
saveXML('foo');

Expected result:

Fatal error: Uncaught exception 'Exception' in 
/home/whatthejeff/php2/segfault.php:6
Stack trace:
#0 [internal function]: PHPUnit_Util_ErrorHandler::handleError(4096, 'Argument 
1 
pass...', '/home/whattheje...', 16, Array)
#1 /home/whatthejeff/php2/segfault.php(16): DOMDocument->saveXML('foo')
#2 {main}
  thrown in /home/whatthejeff/php2/segfault.php on line 6

Actual result:
--
GDB session with PHP 5.4 / xdebug (edited for brevity):
---

[whatthejeff@xdebug php2]$ gdb php

...

(gdb) break zend_vm_execute.h:628
Breakpoint 1 at 0x870e1d: file /home/whatthejeff/php2/Zend/zend_vm_execute.h, 
line 
628.
(gdb) break zend_vm_execute.h:639
Breakpoint 2 at 0x870eb8: file /home/whatthejeff/php2/Zend/zend_vm_execute.h, 
line 
639.
(gdb) run segfault.php
Starting program: /usr/local/bin/php segfault.php

...

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.80.el6_3.6.x86_64 
nss-softokn-freebl-3.12.9-11.el6.x86_64 zlib-1.2.3-27.el6.x86_64
(gdb) c
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 1, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac310, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:629
629 if (fbc->common.arg_info) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac310, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) 
Continuing.

Breakpoint 2, zend_do_fcall_common_helper_SPEC (execute_data=0x77fac0f8, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_vm_execute.h:640
640 if (!zend_execute_internal) {
(gdb) step
644 zend_execute_internal(execute_data, 
RETURN_VALUE_USED(opline) TSRMLS_CC);
(gdb) 
xdebug_execute_internal (current_execute_data=0x77fac0f8, 
return_value_used=0, 
tsrm_ls=0xff0090) at /home/whatthejeff/xdebug/xdebug.c:1506

...

(gdb) 
1547execute_internal(current_execute_data, 
return_value_used 
TSRMLS_CC);
(gdb) step
execute_internal (execute_data_ptr=0x77fac0f8, return_value_used=0, 
tsrm_ls=0xff0090) at /home/whatthejeff/php2/Zend/zend_execute.

Bug #64490 [Opn->Csd]: struct flock undefined on FreeBSD

[stas]

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

 ID: 64490
 Updated by: s...@php.net
 Reported by:ond...@php.net
 Summary:struct flock undefined on FreeBSD
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   GNU kFreeBSD
 PHP Version:5.5.0beta1
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=c342c9b96452c5660c32a6c1a34d9dab9066afef
Log: fix bug #64490 - add __FreeBSD_kernel__ to allowed FreeBSD defs


Previous Comments:

[2013-03-22 18:06:15] krak...@php.net

The following patch has been added/updated:

Patch Name: kfbsd.preprocessor
Revision:   1363975574
URL:
https://bugs.php.net/patch-display.php?bug=64490&patch=kfbsd.preprocessor&revision=1363975574


[2013-03-22 12:32:47] ond...@php.net

Description:

Zend OpCache doesn't build on Debian GNU/kFreeBSD (amd64).

Full build log: 
https://buildd.debian.org/status/fetch.php?pkg=php5&arch=kfreebsd-
amd64&ver=5.5.0~beta1-1&stamp=1363952343


Expected result:

PHP built

Actual result:
--
/bin/bash /build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/libtool --preserve-dup-deps --mode=compile x86_64-
kfreebsd-gnu-gcc  -Iext/opcache/ -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/ -DPHP_ATOM_INC -I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/include -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1 -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib -I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/ereg/regex -I/usr/include/libxml2 -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/mbstring/libmbfl -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl -I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/mbstring/libmbfl/mbfl -I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/mbstring/libmbfl/mbfl -
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/main -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/Zend -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/TSRM -I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/cli-build/-I/usr/include -O2 -Wall -fsigned-char -
fno-strict-aliasing -gstabs -fvisibility=hidden  -prefer-pic -c /build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/opcache/ZendAccelerator.c -o ext/opcache/ZendAccelerator.lo 
libtool: compile:  x86_64-kfreebsd-gnu-gcc -Iext/opcache/ "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/opcache/" -
DPHP_ATOM_INC "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/cli-build/include" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/main" "-I/build/buildd-php5_5.5.0~beta1-
1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1" "-I/build/buildd-php5_5.5.0~beta1-1-
kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/ext/date/lib" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/date/lib" "-
I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-
5.5.0~beta1/ext/ereg/regex" -I/usr/include/libxml2 "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl" 
"-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/ext/mbstring/libmbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-amd64-
MDnVFk/php5-5.5.0~beta1/ext/mbstring/libmbfl/mbfl" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-
build/ext/mbstring/libmbfl/mbfl" "-I/build/buildd-php5_5.5.0~beta1-1-kfreebsd-
amd64-MDnVFk/php5-5.5.0~beta1/cli-build/TSRM" "-I/build/buildd-php5_5.5.0~beta1-
1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/cli-build/Zend" "-I/build/buildd-
php5_5.5.0~beta1-1-kfreebsd-amd64-MDnVFk/php5-5.5.0~beta1/main

Req #38917 [NoF->Opn]: OpenSSL: signing function for spkac

[stas]

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

 ID: 38917
 Updated by: s...@php.net
 Reported by:zeph at purotesto dot it
 Summary:OpenSSL: signing function for spkac
-Status: No Feedback
+Status: Open
 Type:   Feature/Change Request
 Package:OpenSSL related
 Operating System:   Irrilevant
 PHP Version:trunk
 Block user comment: N
 Private report: N



Previous Comments:

[2013-02-18 00:33:52] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


[2012-12-19 15:14:04] queenzeal at gmail dot com

If you want SPKAC support in PHP without having to recompile it, try the latest 
Git version of phpseclib (http://phpseclib.sourceforge.net/). An example of how 
to 
use it:

http://www.frostjedi.com/phpbb3/viewtopic.php?p=389618#p389618


[2012-01-10 10:38:37] jason dot gerfen at gmail dot com

I have added the requested test case and it is included in the patch
as 026.phpt. I have also performed the required testing against the
Openssl 0.9.8x and 1.0.0x. It is attached to the original bug report
#38917. In addition to attaching the proposed patch I have created a
github repo to make maintenance on the patch simple for myself. The
URL is https://github.com/jas-/SPKAC-PHP-OpenSSL.


[2011-12-21 10:49:08] jason dot gerfen at gmail dot com

Once again, please disregard the last message. After researching the 
documentation I found that where I had been using NULL with the 
openssl_csr_sign() function allows for a CA option as well as the SPKAC 
addition to the configargs optional array.

The patch was updated last night to include the 026.phpt test script, as well 
as the five new functions to work with the SPKI provided by keygen tags.

How do patch inclusions work besides posting them to the php internals list?


[2011-12-14 22:10:52] jason dot gerfen at gmail dot com

Please disregard my previous comment. I did a little more digging and am under 
the impression that adding the following to php_openssl_make_REQ() function 
should allow me to create a self signed certificate using the SPKAC NID like so?

if (strcmp(strindex, "SPKAC") == 0) {
 if (!X509_NAME_add_entry_by_txt(subj, strindex, MBSTRING_ASC, (unsigned 
char*)Z_STRVAL_PP(item), -1, -1, 0)){
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "dn: add_entry_by_txt %s -> %s 
(failed)", strindex, Z_STRVAL_PP(item));
  return FAILURE;
 }
}

Would you recommend another method? Please advise.




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=38917


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

Bug #52861 [Opn->Csd]: unset failes with ArrayObject and deep arrays

[stas]

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

 ID: 52861
 Updated by: s...@php.net
 Reported by:mep_eisen at web dot de
 Summary:unset failes with ArrayObject and deep arrays
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   Windows Vista 64
 PHP Version:5.3.3
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

merged as 61099f85857193c223dd62b0c5302507a77cf0ab


Previous Comments:

[2011-11-18 13:49:14] nemo at ikkoku dot de

One can still use unset if one writes:

--- >8 ---
$a = ArrayObject(Array('foo' => Array('bar' => 1)));

// Won't work ($a['foo']['bar'] is still 1)
// Also a notice is displayed: PHP Notice:  Indirect modification of 
// overloaded element of ArrayObject has no effect in php shell code on line ...
var_dump($a);
unset($a['foo']['bar']);
var_dump($a);

// This works
var_dump($a);
$v =& $a['foo'];
unset($v['bar']);
var_dump($a);

// This also works
//$v =& $a['foo']['bar'];
//unset($v);
--- 8< ---


[2011-01-07 12:37:52] auke at muze dot nl

Just checked with php 5.3.3 and there the code runs as expected, so at least 
setting works with a nested array. 

For the record I tried the original bugreport code as well and got the same 
result, on a linux system, 64 bits (debian), but also this notice:

PHP Notice:  Indirect modification of overloaded element of ArrayObject has no 
effect in /var/www/test/test.php on line 22

So at least PHP is honest in that it doesn't work :)


[2011-01-07 12:07:34] auke at muze dot nl

I found a workaround for the problem that suddenly the parent object has any 
property you try to access and has it filled with the previously set array.

If the containing object has its own __get() method which always returns NULL, 
the object is safe again. So this code works as expected:


class IWouldLikeToPointOutABug {

function __get( $name ) {
return NULL;
}

}

$buggy = new IWouldLikeToPointOutABug();

$buggy->bug = new ArrayObject( );

$buggy->bug['foo']['bar'] = true;

echo "This looks normal\r\n";

var_dump( $buggy );

echo "This should be NULL\r\n";

var_dump( $buggy->thisIsNotHere );

One drawback is that you cannot assign properties by reference anymore because 
you're now using the __get() overloading method.
This does not fix the original bug where unsetting fails.

BTW. Our original workaround involved creating our own arrayobject by 
implementing all the array interfaces, but that will not work either. When you 
do this:

$arrayobject['unsetkey']['key'] = $value;

The offsetSet method is never called for 'unsetKey', just the offsetGet. So 
there is no way to implement the correct behaviour.


[2011-01-05 18:51:51] auke at muze dot nl

It's worse than this, ArrayObject gets confused on where to put the data and 
mangles any containing object:

test script:

class IWouldLikeToPointOutABug {

}

$buggy = new IWouldLikeToPointOutABug();

$buggy->bug = new ArrayObject( );

$buggy->bug['foo']['bar'] = true;

echo "This looks normal\r\n";

var_dump( $buggy );

echo "This should be NULL\r\n";

var_dump( $buggy->thisIsNotHere );

Results in:

This looks normal

object(IWouldLikeToPointOutABug)#1 (1) {
  ["bug"]=>
  object(ArrayObject)#2 (0) {
  }
}

This should be NULL

array(1) {
  ["bar"]=>
  bool(true)
}


[2010-09-16 17:23:11] mep_eisen at web dot de

Description:

Using deep arrays unset itself or ArrayObject misbehaves. It silently does 
nothing.
The problem lies in iteration 3 that mixes ArrayObject and classic arrays.

Test script:
---
echo "iteration1\n";

$arr = new ArrayObject();
$arr['foo'] = new ArrayObject

Bug #49348 [Asn->Csd]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)

[stas]

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

 ID: 49348
 Updated by: s...@php.net
 Reported by:BelStudent at yandex dot ru
 Summary:Uninitialized ++$foo->bar; does not cause a notice
 (but ++$bar; does!)
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.*, 6
 Assigned To:    stas
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=0c6d903ce7615a7197cb997d67d98058c3ec5d6a
Log: fix bug #49348 - issue notice on get_property_ptr_ptr when used for read


Previous Comments:

[2013-02-20 08:35:21] dmi...@php.net

I think the fix is fine, but it may go only into 5.5 and above.


[2013-02-19 09:18:04] s...@php.net

Potential fix in this pull: https://github.com/php/php-src/pull/281


[2013-02-19 04:59:16] s...@php.net

The problem here is that get_property_ptr_ptr does not produce notices. It 
doesn't 
because it does not know the fetch type - in some cases it's BP_VAR_W, then it 
shouldn't produce notice, in some it's BP_VAR_RW and then it should. However 
get_property_ptr_ptr doesn't have a parameter to pass this info.

Looks like such parameter needs to be added...


[2009-09-01 08:41:52] sjo...@php.net

I was talking about this:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251

With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With 
++$this->foo, it is BP_VAR_W.


[2009-08-31 22:12:10] j...@php.net

# svn log -r100312 zend_object_handlers.c

r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines

looks like this message should go

---

Stas, care to explain? Uncommenting that will bring back the notice.

And Sjoerd, what did you mean with that comment..?




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=49348


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

Bug #64154 [Fbk]: Many of extensions listed in php.ini but doesnt exist in /ext.

[stas]

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

 ID: 64154
 Updated by: s...@php.net
 Reported by:Yousha dot A at Hotmail dot com
 Summary:Many of extensions listed in php.ini but doesnt
 exist in /ext.
 Status: Feedback
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   All
 PHP Version:5.3.21
 Assigned To:kriscraig
 Block user comment: N
 Private report: N

 New Comment:

They are listed there as a sample of existing extensions so it'd be easier to 
enable them. What's the problem with them?


Previous Comments:

[2013-02-19 18:44:21] kriscr...@php.net

Yeah it's been that way for some time.  I'll ask about it on Internals and see 
if 
we can just remove them or if there's some reason why we want to keep them 
there.


[2013-02-05 11:13:34] Yousha dot A at Hotmail dot com

Description:

Many of extensions listed in PHP.ini's but doesnt exist in /ext folder.
Such as: php_zip, php_pspell, php_pdo_mssql...

Expected result:

Nothing.

Actual result:
--
Nothing.






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

Bug #49348 [Asn]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)

[stas]

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

 ID: 49348
 Updated by: s...@php.net
 Reported by:BelStudent at yandex dot ru
 Summary:Uninitialized ++$foo->bar; does not cause a notice
 (but ++$bar; does!)
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.*, 6
 Assigned To:    stas
 Block user comment: N
 Private report: N

 New Comment:

Potential fix in this pull: https://github.com/php/php-src/pull/281


Previous Comments:

[2013-02-19 04:59:16] s...@php.net

The problem here is that get_property_ptr_ptr does not produce notices. It 
doesn't 
because it does not know the fetch type - in some cases it's BP_VAR_W, then it 
shouldn't produce notice, in some it's BP_VAR_RW and then it should. However 
get_property_ptr_ptr doesn't have a parameter to pass this info.

Looks like such parameter needs to be added...


[2009-09-01 08:41:52] sjo...@php.net

I was talking about this:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251

With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With 
++$this->foo, it is BP_VAR_W.


[2009-08-31 22:12:10] j...@php.net

# svn log -r100312 zend_object_handlers.c

r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines

looks like this message should go

---

Stas, care to explain? Uncommenting that will bring back the notice.

And Sjoerd, what did you mean with that comment..?


[2009-08-27 21:06:36] sjo...@php.net

In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for 
the example code.


[2009-08-25 08:18:09] j...@php.net

Reopened, Gwynne's arguments are rock solid. :)




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=49348


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

Bug #49348 [Asn]: Uninitialized ++$foo->bar; does not cause a notice (but ++$bar; does!)

[stas]

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

 ID: 49348
 Updated by: s...@php.net
 Reported by:BelStudent at yandex dot ru
 Summary:Uninitialized ++$foo->bar; does not cause a notice
 (but ++$bar; does!)
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.*, 6
 Assigned To:    stas
 Block user comment: N
 Private report: N

 New Comment:

The problem here is that get_property_ptr_ptr does not produce notices. It 
doesn't 
because it does not know the fetch type - in some cases it's BP_VAR_W, then it 
shouldn't produce notice, in some it's BP_VAR_RW and then it should. However 
get_property_ptr_ptr doesn't have a parameter to pass this info.

Looks like such parameter needs to be added...


Previous Comments:

[2009-09-01 08:41:52] sjo...@php.net

I was talking about this:
http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_execute.c?revision=286362&view=markup#l251

With ++$foo, type is BP_VAR_RW, which makes sense and gives a notice. With 
++$this->foo, it is BP_VAR_W.


[2009-08-31 22:12:10] j...@php.net

# svn log -r100312 zend_object_handlers.c

r100312 | stas | 2002-10-20 22:22:04 +0300 (Sun, 20 Oct 2002) | 2 lines

looks like this message should go

---

Stas, care to explain? Uncommenting that will bring back the notice.

And Sjoerd, what did you mean with that comment..?


[2009-08-27 21:06:36] sjo...@php.net

In _get_zval_cv_lookup(), type is BP_VAR_W, while it should be BP_VAR_RW for 
the example code.


[2009-08-25 08:18:09] j...@php.net

Reopened, Gwynne's arguments are rock solid. :)


[2009-08-25 07:13:46] gwy...@php.net

Actually, this is a valid problem; the problem described by bug #21008 is a 
different issue. There seems to be some confusion as to whether it should be 
fixed or not, but it's neither a duplicate nor bogus.

Specifically, bug #21008 describes an issue with setting a variable to a value, 
where this report describes an issue with updating a variable. These are two 
distinct operations, and are handled differently.

More to the point, the following code throws a notice:


That the code described by this bug doesn't is an inconsistency.




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=49348


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

Bug #61930 [Asn->Csd]: openssl corrupts ssl key resource when using openssl_get_publickey()

[stas]

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

 ID: 61930
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:openssl corrupts ssl key resource when using
 openssl_get_publickey()
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:OpenSSL related
 Operating System:   *
 PHP Version:5.4.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=7b0107cc5d3d90655957680ef9cf916dce6875a7
Log: fix bug #61930: openssl corrupts ssl key resource when using 
openssl_get_publickey()


Previous Comments:

[2012-05-03 20:21:08] s...@php.net

The problem happens because php_openssl_evp_from_zval on receiving resource 
with 
public key, is doing just this:


if (resourceval) {
*resourceval = Z_LVAL_PP(val);
}

and then:

return (EVP_PKEY*)what;

while openssl_pkey_get_public() does this:

Z_TYPE_P(return_value) = IS_RESOURCE;
pkey = php_openssl_evp_from_zval(cert, 1, NULL, 1, &Z_LVAL_P(return_value) 
TSRMLS_CC);

so the refcount of the resource in return_value is never increased, even though 
it is assigned now to another variable. When the return_value is freed, so is 
the resource, thus corrupting data in $key.


[2012-05-03 20:18:08] s...@php.net

Description:

If openssl_get_publickey() is applied to a key resource, the resource that 
comes 
out of it has wrong refcount and if freed, the argument of 
openssl_get_publickey() gets freed too. 

Test script:
---
If we have a certificate in $cert and data in $data and valid signature in 
$sign, this works:


$key = openssl_get_publickey($cert);
var_dump(openssl_verify($data, $sig, $key));

however this does not:

$key = openssl_get_publickey($cert);
var_dump(openssl_get_publickey($key));
var_dump(openssl_verify($data, $sig, $key));

it produces errors like this:


Warning: openssl_verify(): 4 is not a valid OpenSSL X.509/key resource in 
/Users/smalyshev/osslbug.php on line 29

Warning: openssl_verify(): supplied key param cannot be coerced into a public 
key in /Users/smalyshev/osslbug.php on line 29








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

Bug #53634 [Asn->Csd]: unknown property when writing to DateInterval::$days

[stas]

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

 ID: 53634
 Updated by: s...@php.net
 Reported by:danielc at analysisandsolutions dot com
 Summary:unknown property when writing to DateInterval::$days
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   linux
 PHP Version:5.3SVN-2010-12-30 (SVN)
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

$days is not writable by design of DateInterval since it's a derived property. 
So 
not being able to write it is not a bug. If additional functionality is needed, 
please create FR or RFC describing how it should work.


Previous Comments:

[2011-01-30 13:59:58] danielc at analysisandsolutions dot com

Why should days be read only?  All other properties are writable.  Days needs 
to be writable too.  Writing to various properties is necessary when 
overloading the date classes (to compensate for bugs, etc).


[2011-01-30 11:57:20] s...@php.net

Hmm... Actually you're not supposed to be writing to days property, it should 
be read only. I'll fix it.


[2011-01-24 18:39:45] danielc at analysisandsolutions dot com

While the recent commit removes the fatal error, the property can not be 
written to.  Here is the output of the initial test script (above) as of svn 
revision 307713:

S: 8
DAYS: -9
DAYS: -9


[2011-01-24 03:49:50] s...@php.net

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/.
 
Thank you for the report, and for helping us make PHP better.




[2010-12-30 22:15:05] danielc at analysisandsolutions dot com

Description:

One can not set the DateInterval::$days property.  It is readable.  All other 
properties of DateInterval shown in var_dump() are writeable.

While similar to Bug #52738, this involves an actual property of the 
DateInterval class.


Test script:
---
$i = new DateInterval('P1D');
$i->s = 8;
echo "S: $i->s\n";
echo "DAYS: $i->days\n";
$i->days = 6;
echo "DAYS: $i->days\n";


Expected result:

S: 8
DAYS: -9
DAYS: 6


Actual result:
--
S: 8
DAYS: -9
PHP Fatal error:  main(): Unknown property (days) in /home/danielc/test.php on 
line 7







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

Bug #60798 [Asn->Fbk]: Regression: uninitialized memory in openssl_encrypt() with zero-length $data

[stas]

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

 ID: 60798
 Updated by: s...@php.net
 Reported by:ktk at enterprise dot bidmc dot harvard dot edu
 Summary:Regression: uninitialized memory in
 openssl_encrypt() with zero-length $data
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   Slackware x86_64
 PHP Version:5.3.9
 Assigned To:scottmac
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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

Seems to work fine in 5.4.


Previous Comments:

[2012-01-19 03:08:18] ktk at enterprise dot bidmc dot harvard dot edu

Description:

A regression was introduced in php 5.3.9 to the file ext/openssl/openssl.c 
which causes openssl_encrypt("", "aes-128-cbc", "password") to use 
uninitialized memory when calling the underlying AES_cbc_encrypt() whenever the 
length of the $data argument is zero.  This results in either a corrupted 
return value, or a segmentation fault, depending upon what exists in php's 
memory heap.

I bisected the code difference between php 5.3.8 and 5.3.9 and have attached 
the errant patch to this bug report.

The problem patch introduces the following code, which for reasons unknown 
fails to call the update function whenever the length of the data argument is 
zero:
-   EVP_EncryptUpdate(&cipher_ctx, outbuf, &i, ...);
+   if (data_len > 0) {
+   EVP_EncryptUpdate(&cipher_ctx, outbuf, &i, ...);
+   }

Reverting the attached patch fixes the problem for me.

I'm seeing this problem on both x86_64 (64 bit) and i686 (32 bit) processor 
architectures.  OS is Slackware in both cases, with php linked against openssl 
version 1.0.0g (ditto for openssl 1.0.0e and 1.0.0f), glibc 2.14.1 and compiled 
with gcc 4.5.3.

The corruption/segfault occurs whether or not an initialization vector is 
passed to the function; the only requirement it seems is the zero-length data 
(ergo, the omission of the call to EVP_EncryptUpdate()).

Test script:
---


Expected result:

string(24) "xrQjTh0HCclFET5PKpYH9w=="
string(24) "xrQjTh0HCclFET5PKpYH9w=="

Warning: openssl_encrypt(): Using an empty Initialization Vector (iv) is 
potentially insecure and not recommended in test.php on line 7
string(24) "xrQjTh0HCclFET5PKpYH9w=="
string(24) "xrQjTh0HCclFET5PKpYH9w=="

Actual result:
--
GNU gdb (GDB) 7.2
Reading symbols from /usr/bin/php...done.
(gdb) set args test.php
(gdb) run
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
string(24) "AMa0I04dBwnJRRE+TyqWB/c="
string(24) "xrQjTh0HCclFET5PKpYH9w=="

Warning: openssl_encrypt(): Using an empty Initialization Vector (iv) is 
potentially insecure and not recommended in test.php on line 7
string(24) "xrQjTh0HCclFET5PKpYH9w=="

Program received signal SIGSEGV, Segmentation fault.
0xb767cb7c in AES_cbc_encrypt () from /lib/libcrypto.so.1
(gdb) 






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

Req #48847 [Opn->Nab]: debug_backtrace() doesn't reference arguments in stack in some cases

[stas]

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

 ID: 48847
 Updated by: s...@php.net
 Reported by:an0nym at narod dot ru
 Summary:debug_backtrace() doesn't reference arguments in
 stack in some cases
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.2.10, 5.3.0
 Block user comment: N
 Private report: N

 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.

Modifying debug traces is definitely not a supported functionality.


Previous Comments:

[2009-08-25 09:04:50] an0nym at narod dot ru

I agree that manual doesn't document anything related to this issue - according 
to manual behaviour in this particular case is undefined, so 
de jure this is not a bug. 

However, I think behaviour should be at least equal in both cases I 
provided. Moreover, I don't see the point of triggering recoverable 
error when you can't influence the cause of it. 

> I am surprised that it is possible to change function
parameters in the error handler, and I don't think it is supported
behavior. 
I think it is OK to change function parameters in the error handler for 
catchable error which these function parameters were reason for. Maybe 
debug_backtrace() is not the appropriate tool to get there parameters, 
but there is no other.


[2009-08-25 07:21:42] sjo...@php.net

Thank you for your bug report.

Why do you think it should be possible what you are trying to do? The 
documentation for debug_backtrace does not describe that it returns a 
reference. I am surprised that it is possible to change function parameters in 
the error handler, and I don't think it is supported behavior.


[2009-07-08 08:00:43] an0nym at narod dot ru

Description:

When argument of function or method is defined with type declaration and 
default value and is called with some value of this argument, 
debug_backtrace() doesn't reference this argument of function in stack. 

When function definition is the same except argument doesn't have 
default value, everything goes normal. 

Reproduce code:
---


Expected result:

bool(false) bool(true)
bool(false) bool(true)

Actual result:
--
bool(false) bool(true)
bool(true) bool(false)






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

Req #53904 [Opn->Nab]: Use of dynamic class name in namespace construction

[stas]

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

 ID: 53904
 Updated by: s...@php.net
 Reported by:dave at mudsite dot com
 Summary:Use of dynamic class name in namespace construction
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux x86
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 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.

You can use __NAMESPACE__ for dynamically constructing namespaced names.


Previous Comments:

[2011-02-01 23:12:29] dave at mudsite dot com

I guess I should note, that the variable coming into this function would be 
something like:

'user'

user.php--
From manual page: http://www.php.net/language.namespaces.dynamic
---

When not using namespaces the following code works just fine

Function loadClass ($class) {
$this->obj = new $class();
}

However, when attempting to implement namespaces:

function loadClass ($class) {
$this->obj = \classes\$class();
}

Throws an "Parse error: syntax error, unexpected T_VARIABLE, expecting 
T_STRING".  Which is kind of silly, since the corrected function looks like:

function loadClass ($class) {
$class = '\classes\\'.$class;
$this->obj = new $class();
}


Upon reading other bugs that query about using dynamic content in namespaces, 
I'm confused as to why the latter example above actually does work if 
namespaces 
are computed on compile time, when the class isn't known at compile time.

Expected result:

I kindly request that you be able to use dynamic elements when using namespaces.







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

Req #31228 [Opn->Nab]: __autoload analog for function libs

[stas]

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

 ID: 31228
 Updated by: s...@php.net
 Reported by:phoeniks2k at mail dot ru
 Summary:__autoload analog for function libs
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This issue is discussed in https://wiki.php.net/rfc/autofunc, please feel free 
to 
cooperate with the author and develop the RFC.


Previous Comments:

[2004-12-21 11:51:55] phoeniks2k at mail dot ru

Description:

It'll be usefull to have autoload analog for functions, that are not declared 
yet. It's possible to use static methods of a claas , but so class is used as a 
namespace. that's not good.







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

Bug #50956 [Opn->Fbk]: SOAP-ERROR: parsing schema

[stas]

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

 ID: 50956
 Updated by: s...@php.net
 Reported by:tony at marston-home dot demon dot co dot uk
 Summary:SOAP-ERROR: parsing schema
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   Windows XP
 PHP Version:5.2.12
 Block user comment: N
 Private report: N

 New Comment:

Could you provide the full WSDL that exhibits this behavior?


Previous Comments:

[2010-06-16 01:00:40] rvestra at unm dot edu

Can anyone provide feedback on this it would really help?  I am running across 
the same problem.  I get this error on the documentation tag as follows.

"SOAP-ERROR: Parsing Schema: unexpected  in schema"


[2010-02-07 19:10:28] tony at marston-home dot demon dot co dot uk

Description:

I am calling a soap service using the WSDL supplied by the service provider, 
but it is failing when I try to create the soap client. The error message is:

SOAP-ERROR: Parsing Schema: unexpected  in element


Reproduce code:
---
The wsdl file contains entries such as:


  

blah blah blah

  
  




  


If I put '' around the  element the error 
disappears.


Expected result:

As the  element is merely there for documentation purposes it 
should be ignored instead of causing an error.







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

Req #64175 [Opn->Csd]: [PATCH] Added HTTP codes as of RFC 6585

[stas]

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

 ID: 64175
 Updated by: s...@php.net
 Reported by:jonh dot wendell at gmail dot com
 Summary:[PATCH] Added HTTP codes as of RFC 6585
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:master-Git-2013-02-08 (Git)
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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:

[2013-02-08 17:42:36] jonh dot wendell at gmail dot com

Description:

Added descriptions for the new HTTP codes:

- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 511 Network Authentication Required








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

Bug #64166 [Opn]: quoted-printable-encode stream filter incorrectly discarding whitespace

[stas]

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

 ID: 64166
 Updated by: s...@php.net
 Reported by:slusarz at curecanti dot org
 Summary:quoted-printable-encode stream filter incorrectly
 discarding whitespace
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   Linux
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

The patch seems to have problems with split writes, see my comments there.


Previous Comments:

[2013-02-07 19:41:22] slusarz at curecanti dot org

Added pull request with fix that seems to work (w/unit test):

https://github.com/php/php-src/pull/272


[2013-02-07 01:14:58] slusarz at curecanti dot org

Just kidding... apparently there's a difference between "filter" and "stream 
filter".  Sorry for the noise.


[2013-02-07 01:14:09] slusarz at curecanti dot org

This is actually a stream *filter* issue, so put in filter queue.


[2013-02-07 00:49:44] slusarz at curecanti dot org

Description:

The QP stream filter is incorrectly discarding whitespace at the end of the 
lines.  The quoted_printable_encode() method does not have this issue.

This is troublesome when attempting to save flowed text/plain data, as it 
causes the data to lose its flowed formatting.  (I realize that RFC 3676 says 
flowed text SHOULD NOT be encoded in QP, but this is an (arguably) outdated 
policy restriction and not a technical restriction).

Test script:
---
 76
));
fwrite($fp, $data);
rewind($fp);

print quoted_printable_encode($data) . "\n";
print stream_get_contents($fp);

Expected result:

FIRST=20
SECOND
FIRST=20
SECOND

Actual result:
--
FIRST=20
SECOND
FIRST
SECOND






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

Bug #62524 [Opn->Csd]: fopen follows redirects for non-3xx statuses

[stas]

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

 ID: 62524
 Updated by: s...@php.net
 Reported by:mike dot hall at twistdigital dot co dot uk
 Summary:fopen follows redirects for non-3xx statuses
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=5382e156f925603ef0f65b9cc4fed29cbe2dce9b
Log: Fix bug #62524, only follow redirects in file streams for 3xx HTTP statuses


Previous Comments:

[2012-11-25 02:15:33] wes at serverdensity dot com

I've submitted a patch for this via Github pull request: 
https://github.com/php/php-src/pull/236


[2012-07-12 14:34:17] Sjon at hortensius dot net

A more complete example confirms this behavior:

I also fixed some syntax errors

http://php.net', true, 201);

if (isset($_GET['waa']))
return;

$context = stream_context_create(array(
"http" => array(
"method"  => "POST",
"header"  => "Content-Length: 13",
"content" => "{\"foo\":\"bar\"}",
),
));

$fp = fopen('http://'.$_SERVER['SERVER_NAME']. $_SERVER['PHP_SELF'] .'?waa=1', 
'r', null, $context);
print(stream_get_contents($fp));


[2012-07-10 16:00:52] mike dot hall at twistdigital dot co dot uk

Description:

The HTTP location header can either be used to direct the user to another 
resource (when accompanied by a 3xx status code) or to inform the user of the 
location of the document they just created (with a 2xx) status code.

It doesn't make sense to treat the location header as a redirect in the second 
context - the location header indicates a redirect only when accompanied by a 
3xx 
status code.

Currently, PHP follows Location headers as if they are redirects regardless of 
the returned status code.

Test script:
---
$context = stream_context_create([
"http" => [
"method"  => "POST"
"header"  => "Content-Length: 13"
"content" => "{\"foo\":\"bar\"}",
],
]);

// Returns HTTP/1.1 201 Created
// Location: http://example.com/mydb/documentid
//
// {"status":"ok"}
$fp = fopen('http://example.com/mydb', 'r', null, $context);
$data = stream_get_contents($fp);

list($headers, $body) = explode("\r\n\r\n", $data, 2);
echo $body;

Expected result:

{"status":"ok"}

Actual result:
--
{"foo":"bar"}






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

Req #60524 [Opn->Csd]: specify temp dir by php.ini

[stas]

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

 ID: 60524
 Updated by: s...@php.net
 Reported by:mail+bugs dot php dot net at kazik dot de
 Summary:specify temp dir by php.ini
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Filesystem function related
 Operating System:   *
 PHP Version:*
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

merged into 5.5 as 475a644bd84c071da04b4272b829a187a2c6d282


Previous Comments:

[2012-05-10 15:27:56] mail+bugs dot php dot net at kazik dot de

Added patch for 5.3.4, of course (and not 4.3.4)


[2012-05-10 15:25:59] mail+bugs dot php dot net at kazik dot de

Added patch for 4.3.4


[2011-12-14 14:33:53] mail+bugs dot php dot net at kazik dot de

Description:

This patch (against 5.3.8) adds a new php.ini directive to specify the path for 
the temporary files.

Why:
If, for security reasons, every user is only allowed to use their own home 
directories, it's not possible to specify their own tmp dir (e.g. 
"/home/user/tmp"). The directory for uploading and session can already be 
specified. Since all users may use the same php.ini (different [HOST=domain] 
entries, [1]) it's not possible to set the environment TMPDIR variable, because 
it would affect all users.

[1] http://php.net/manual/en/ini.sections.php

Test script:
---
ini: system_tmp_dir = "/home/user/tmp"

php: var_export(sys_get_temp_dir());

Expected result:

'/home/user/tmp'

Actual result:
--
'/tmp' (depends on system configuration)






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

Bug #46439 [Opn->Csd]: file upload implementation is flawed

[stas]

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

 ID: 46439
 Updated by: s...@php.net
 Reported by:tom at punkave dot com
 Summary:file upload implementation is flawed
-Status: Open
+Status: Closed
 Type:   Bug
 Package:cURL related
 Operating System:   *
 PHP Version:5.*, 6CVS (2009-01-21)
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

Fix as per RFC merged into 5.5.


Previous Comments:

[2013-01-09 01:00:24] s...@php.net

See https://wiki.php.net/rfc/curl-file-upload for fix proposal & implementation.


[2012-08-11 10:13:44] kristo at waher dot net

What if you are not actually trying to send a file and it's instead a POST 
value 
that starts with an @? What if you take user values from a website form and 
submit these values with post to another service and user writes '@config.php' 
to one of the form values? Problem here is that cURL in PHP treats the POST 
array the exact same way, any value could be a link to a file, which creates a 
huge loophole or a lot of extra work for you to filter through all POST values 
to make sure they are not pointers to files when used with cURL.

In fact, it is not possible to even make a POST request at the moment with cURL 
if one of the POST values starts with an @. There's no regular expression 
check, 
no formatting you'd have to follow, just a single (very common) character. What 
if you want to send Twitter handle and user writes @kristovaher?

In fact, it is so bad that you cannot even escape the character with \@, cURL 
will submit it without unescaping it. And if you don't have any control about 
the API on the other side (that would unescape it themselves), cannot make that 
POST request! You cannot make a POST API request to Twitter that is a reply to 
another user, for example.

I just wish PHP developers had the foresight to implement something like 
CURLOPT_FILEFIELDS in cURL, it's insane amount of double-validation I have to 
do 
in my API - that doesn't upload any files - at the moment just because of this 
potential security loophole. I love PHP, but these implementations are 
sometimes 
such a headache.


[2012-01-17 21:40:50] gmblar+php at gmail dot com

There is no function to escape the "@" in the CURLOPT_POSTFIELDS array and in 
this example 
its not possible to remove or replace the "@".

$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL=> 'http://www.example.com/',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_POSTFIELDS => array(
'username' => 'foobar',
// Users may have strange passwords. Should be transfered as text.
'password' => '@/etc/hosts',
// Upload image.
'picture'  => '@/var/www/avatars/foobar.jpg'
)
));
curl_exec($curl);
curl_close($curl);


My suggestion is to escape the password in this escape with \@ and then thread 
as text.


[2009-05-03 21:04:44] paj...@php.net

tbd


[2009-01-21 20:08:07] tom at punkave dot com

htmlencode() won't escape @. Neither will htmlentities(). it's a security bug 
that no amount of reasonable prudence on the part of programmers who haven't 
read this particular bug report will address. And there is no reason why 
programmers would expect that filtering input would be necessary when they are 
passing individual fields to a function that ought to be ready to escape them 
(and in fact does, apart from the leading @ thing).

The documentation needs to be fixed at a minimum. It would be a much better 
idea to get rid of the broken behavior. The @ prefix is a bad idea (what if I 
want to pass @?) and with the current lack of documentation it's a security 
hole.

This needs to be patched or at least documented.




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=46439


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

Bug #60833 [Opn->Csd]: self, parent, static behave inconsistently case-sensitive

[stas]

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

 ID: 60833
 Updated by: s...@php.net
 Reported by:mario at include-once dot org
 Summary:self, parent, static behave inconsistently
 case-sensitive
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=184db665ebdb6a2717d15e956391f6d88e1d05c6
Log: fix bug #60833 - self, parent, static behave inconsistently case-sensitive


Previous Comments:

[2012-01-21 20:31:19] mario at include-once dot org

Description:

"parent" and "self", "static" LSB tokens behave inconsistent when it comes to 
case-sensitivity. Class names in PHP are case-insensitive, but these three 
keywords aren't always, as the parser sees them as raw T_STRINGs.

That is, you cannot do `SELF::CNST` or `SELF::$VAR` or `SELF::METHOD()`
But it's possible to use `constant("SELF::CNST")` or `call_user_func` with 
uppercase `SELF` keyword.

Likewise do you get an error message for `class SELF {}` declarations, even if 
the other error messages indicate the uppercase class name wasn't reserved.



Patch: It's just a matter of exchanging `memcmp` against `strncasecmp` in 
`zend_get_class_fetch_type`. Not sure if that is a sufficient substition 
though. It works well, and all comparisons are shadowed by a length check 
anyway, so little worries about NUL byte length discrepancies.
Performance: No idea. This affects the parser, hard to test without memory 
exhausting script (eval to redeclare classes). But in clang build no measurable 
difference (again, pointless test with only x1 runs).



Should this be fixed?
Well, of course. This might not matter to most people, never run into this 
myself IIRC, but it does in fact come up as issue occasionally:
http://stackoverflow.com/questions/8953208/fatal-error-class-self-not-found
Also because it's not mentioned in the manual yet.
http://www.php.net/manual/en/language.oop5.late-static-bindings.php
(I shall commit a note there myself...)
And of course, the whole PHP 5.3 series doesn't support it. But that doesn't 
mean it shouldn't be normalized in later versions, specifically the upcoming 
5.4. ("Never too later to fix a mistake.." bla bla)


Test script:
---
class a {
const C = "C";
function __construct() {
print SELF::C;
}

}
new a;








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

Bug #63159 [Opn->Fbk]: Passing > 1 additional module to php_module_startup causes a segfault

[stas]

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

 ID: 63159
 Updated by: s...@php.net
 Reported by:slangley at google dot com
 Summary:Passing > 1 additional module to php_module_startup
 causes a segfault
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   N/A
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

Could you add some (short) code that would help to reproduce the problem?


Previous Comments:

[2012-09-25 10:34:03] slangley at google dot com

Not sure how that might be ...

Here's the signature for php_module_startup

int php_module_startup(sapi_module_struct *sf, zend_module_entry 
*additional_modules, uint num_additional_modules);

The parameter num_additional_modules suggests that more then one module_entry 
can be passed in the additional_modules argument, but it's only a pointer not 
an 
array of pointers.

Here's the signature for php_register_extensions, which is called from 
php_module_startup.

int php_register_extensions(zend_module_entry **ptr, int count TSRMLS_DC);

This more correctly takes an array of pointers.

I don't know why this wasn't fixed when first reported in 2004 - I couldn't 
find 
any more information than the thread I linked.


[2012-09-25 09:42:22] larue...@php.net

I am not sure, is this just a wrong usage of ZEND API?


[2012-09-25 02:06:43] slangley at google dot com

Description:

This was reported in 2004 but seemingly never fixed?

http://marc.info/?l=php-internals&m=110257814320454&w=2

php_module_startup expects a pointer to an array of structures of 
zend_module_entry. This gets passed to php_register_extensions which expects an 
array of points to structures of zend_module_entry. php_register_extensions 
then 
tries to use pointer arithmetic to walk along the passed array, which will 
cause a 
seg fault.

I will make a pull request on github with this fix.

Test script:
---
Write a SAPI, pass > 2 additional modules to php_module_startup.







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

Bug #55731 [Nab->Csd]: __get after __unset

[stas]

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

 ID: 55731
 Updated by: s...@php.net
 Reported by:421034509 at qq dot com
 Summary:__get after __unset
-Status: Not a bug
+Status: Closed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   windows xp
 PHP Version:5.3.8
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

fix for bug #63462 should also fix this one.


Previous Comments:

[2012-11-08 08:13:17] ocramius at gmail dot com

I got pointed here after filing #63462 ( https://bugs.php.net/bug.php?id=63462 
).

Shouldn't the `getter_guard` be disabled for "\0Example\0p1: (laurence's 
example) when already in the context of `__get` (and similar logic for all the 
other magic methods)? 

I have absolutely no understanding of PHP internals about this, but I wouldn't 
expect the magic getter to work again for the same property when we already 
know it was the requested one.

This is actually a (quite problematic) bug for me since it denies any action on 
unset properties, which is a feature I need when working with proxies.

If I understand this correctly, at 
https://github.com/php/php-src/blob/6ba376f552238de643a665d355fd5e59c40315b5/Zend/zend_object_handlers.c#L559-572
 the guard is used. I don't understand why `guard->in_set` isn't checked the 
second time though. Does `zend_get_property_guard` retrieve a different item 
for different `property_info`?


[2011-09-22 03:36:35] 421034509 at qq dot com

Thank you!I got it!


[2011-09-22 01:28:25] larue...@php.net

No, if the property is private, and the getter is called out of call 
entry(means 
access a private property out of scope), zend vm will return NULL,  but 
zend_read_property will assume as a "public property name", since PHP is a 
flexible language.


[2011-09-22 01:18:53] 421034509 at qq dot com

When get_property_info successed in the Example class,
if the private property is defined but be unsetted,zend vm return a property 
info with name "\0Example\0propertyname",
but if the property is undefined(or defined but not be unsetted),zend vm return 
a property info with name "propertyname".
Is that true?


[2011-09-22 01:17:55] larue...@php.net

because there is no '\0Example\0p3' in property_info of  Example class entry




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=55731


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

Bug #63462 [Asn->Csd]: Magic methods called twice for unset protected properties

[stas]

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

 ID: 63462
 Updated by: s...@php.net
 Reported by:ocramius at gmail dot com
 Summary:Magic methods called twice for unset protected
 properties
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:5.4.8
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=33b104c778c5c0e5446671397aaddd66efa4a7bc
Log: fix bug #63462 (Magic methods called twice for unset protected properties)


Previous Comments:

[2013-01-14 08:18:11] s...@php.net

https://github.com/php/php-src/pull/258 should fix it (will be applied soon if 
no 
problem is found).


[2012-11-08 07:34:06] larue...@php.net

similar to #55731


[2012-11-08 05:47:23] ocramius at gmail dot com

I've added the failing test case as a PR at 
https://github.com/php/php-src/pull/229


[2012-11-08 05:40:59] ocramius at gmail dot com

Description:

When un-setting a private or protected property of an object, magic methods get 
called twice when that property is accessed.

Test script:
---
https://gist.github.com/4037010
(will provide PR with the test later)

Expected result:

Each of the magic methods presented in the test script should be called only 
once per checked property. 

Actual result:
--
Each of the magic methods are called twice for private or protected properties 
that were unset.






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

Bug #63462 [Asn]: Magic methods called twice for unset protected properties

[stas]

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

 ID: 63462
 Updated by: s...@php.net
 Reported by:ocramius at gmail dot com
 Summary:Magic methods called twice for unset protected
 properties
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:5.4.8
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

https://github.com/php/php-src/pull/258 should fix it (will be applied soon if 
no 
problem is found).


Previous Comments:

[2012-11-08 07:34:06] larue...@php.net

similar to #55731


[2012-11-08 05:47:23] ocramius at gmail dot com

I've added the failing test case as a PR at 
https://github.com/php/php-src/pull/229


[2012-11-08 05:40:59] ocramius at gmail dot com

Description:

When un-setting a private or protected property of an object, magic methods get 
called twice when that property is accessed.

Test script:
---
https://gist.github.com/4037010
(will provide PR with the test later)

Expected result:

Each of the magic methods presented in the test script should be called only 
once per checked property. 

Actual result:
--
Each of the magic methods are called twice for private or protected properties 
that were unset.






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

Bug #63982 [Opn->Csd]: isset() inconsistently produces a fatal error on protected property

[stas]

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

 ID: 63982
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:isset() inconsistently produces a fatal error on
 protected property
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4Git-2013-01-13 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=1a96fe0b3260b4b63627cf69d71a5b350ad3163f
Log: fix bug #63982: isset() inconsistently produces a fatal error on protected 
property


Previous Comments:

[2013-01-14 00:21:03] s...@php.net

Description:

protectedProperty->foo));

This produces fatal error. However this:

var_dump(isset($test->protectedProperty));

produces bool(false) - even though the very same protected property is 
accessed. 
This is obviously inconsistent. It looks like this is caused by this code in 
zend_std_read_property:

property_info = zend_get_property_info_quick(zobj->ce, member, (zobj-
>ce->__get != NULL), key TSRMLS_CC);

This sets property getter to "silent" for "get" requests, but not for "isset" 
requests, even though code immediately above is:

silent = (type == BP_VAR_IS);

But 'silent' value is ignored for zend_get_property_info_quick and it is 
allowed 
to produce the fatal error, even though has_property() handler in this 
situation 
does not. 

Test script:
---
protectedProperty->foo));

Expected result:

bool(false)

Actual result:
--
Fatal error: Cannot access protected property Test::$protectedProperty 






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

Bug #46439 [Opn]: file upload implementation is flawed

[stas]

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

 ID: 46439
 Updated by: s...@php.net
 Reported by:tom at punkave dot com
 Summary:file upload implementation is flawed
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   *
 PHP Version:5.*, 6CVS (2009-01-21)
 Block user comment: N
 Private report: N

 New Comment:

See https://wiki.php.net/rfc/curl-file-upload for fix proposal & implementation.


Previous Comments:

[2012-08-11 10:13:44] kristo at waher dot net

What if you are not actually trying to send a file and it's instead a POST 
value 
that starts with an @? What if you take user values from a website form and 
submit these values with post to another service and user writes '@config.php' 
to one of the form values? Problem here is that cURL in PHP treats the POST 
array the exact same way, any value could be a link to a file, which creates a 
huge loophole or a lot of extra work for you to filter through all POST values 
to make sure they are not pointers to files when used with cURL.

In fact, it is not possible to even make a POST request at the moment with cURL 
if one of the POST values starts with an @. There's no regular expression 
check, 
no formatting you'd have to follow, just a single (very common) character. What 
if you want to send Twitter handle and user writes @kristovaher?

In fact, it is so bad that you cannot even escape the character with \@, cURL 
will submit it without unescaping it. And if you don't have any control about 
the API on the other side (that would unescape it themselves), cannot make that 
POST request! You cannot make a POST API request to Twitter that is a reply to 
another user, for example.

I just wish PHP developers had the foresight to implement something like 
CURLOPT_FILEFIELDS in cURL, it's insane amount of double-validation I have to 
do 
in my API - that doesn't upload any files - at the moment just because of this 
potential security loophole. I love PHP, but these implementations are 
sometimes 
such a headache.


[2012-01-17 21:40:50] gmblar+php at gmail dot com

There is no function to escape the "@" in the CURLOPT_POSTFIELDS array and in 
this example 
its not possible to remove or replace the "@".

$curl = curl_init();
curl_setopt_array($curl, array(
CURLOPT_URL=> 'http://www.example.com/',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_POSTFIELDS => array(
'username' => 'foobar',
// Users may have strange passwords. Should be transfered as text.
'password' => '@/etc/hosts',
// Upload image.
'picture'  => '@/var/www/avatars/foobar.jpg'
)
));
curl_exec($curl);
curl_close($curl);


My suggestion is to escape the password in this escape with \@ and then thread 
as text.


[2009-05-03 21:04:44] paj...@php.net

tbd


[2009-01-21 20:08:07] tom at punkave dot com

htmlencode() won't escape @. Neither will htmlentities(). it's a security bug 
that no amount of reasonable prudence on the part of programmers who haven't 
read this particular bug report will address. And there is no reason why 
programmers would expect that filtering input would be necessary when they are 
passing individual fields to a function that ought to be ready to escape them 
(and in fact does, apart from the leading @ thing).

The documentation needs to be fixed at a minimum. It would be a much better 
idea to get rid of the broken behavior. The @ prefix is a bad idea (what if I 
want to pass @?) and with the current lack of documentation it's a security 
hole.

This needs to be patched or at least documented.


[2009-01-21 19:56:56] j...@php.net

It's security hole only if you don't filter the input..




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=46439


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

Req #45351 [Opn]: Exception::getTrace() should return 'object' array-element

[stas]

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

 ID: 45351
 Updated by: s...@php.net
 Reported by:lasse100 at planet dot nl
 Summary:Exception::getTrace() should return 'object'
 array-element
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.3
 Block user comment: N
 Private report: N

 New Comment:

Unfortunately, proposed solution breaks the fix for bug #29368, since it keeps 
the 
reference to the constructed option. Better solution is needed (maybe better 
patch 
for #29368).


Previous Comments:

[2013-01-04 19:38:24] lstro...@php.net

A test is missing for the new functionality.


[2012-08-16 07:38:05] jachym dot tousek at gmail dot com

Why is this feature not yet integrated in PHP?


[2008-06-24 20:23:26] lasse100 at planet dot nl

Description:

As in function debug_backtrace(), the method Exception::getTrace() should 
return a array with a 'object' element, representing the current object.

The method Exception::getTrace() should also have a $provide_object parameter 
like the parameter in function debug_backtrace(), to disable the 
'object'-element in the array.

Reproduce code:
---
bar = $bar;
echo 'debug_backtrace: ';
var_dump(debug_backtrace());
echo '';
throw new Exception('Foo throws an exception!');
}
}
try {
$foo = new Foo('test');
} catch (Exception $e) {
echo 'Exception::getTrace(): ';
var_dump($e->getTrace());
echo '';
}
?>

Expected result:

debug_backtrace:

array(1) {
  [0]=>
  array(7) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  &string(4) "test"
}
  }
}

Exception::getTrace():

array(1) {
  [0]=>
  array(6) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  string(4) "test"
}
  }
}

Actual result:
--
debug_backtrace:

array(1) {
  [0]=>
  array(7) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["object"]=>
object(Foo)#1 (1) {
  ["bar"]=>
  string(4) "test"
}
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  &string(4) "test"
}
  }
}

Exception::getTrace():

array(1) {
  [0]=>
  array(6) {
["file"]=>
string(50) "C:\server\apache\htdocs\forum\htdocs\bugreport.php"
["line"]=>
int(13)
["function"]=>
string(11) "__construct"
["class"]=>
string(3) "Foo"
["type"]=>
string(2) "->"
["args"]=>
array(1) {
  [0]=>
  string(4) "test"
}
  }
}






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

Bug #29368 [Csd->ReO]: The destructor is called when an exception is thrown from the constructor

[stas]

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

 ID: 29368
 Updated by: s...@php.net
 Reported by:fixxxer at php5 dot ru
 Summary:The destructor is called when an exception is thrown
 from the constructor
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
-PHP Version:5.0.0
+PHP Version:5.4.0
 Assigned To:helly
 Block user comment: N
 Private report: N

 New Comment:

This bug is still reproducible in 5.4 with this code:

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




[2004-07-24 22:43:10] fixxxer at php5 dot ru

Description:

The destructor is called if throwing an exception from the constructor. This 
seems at least illogical and it's contrary to usual behaviour of alike 
languages like C++ where destructor is not called in this case.

Reproduce code:
---


Expected result:

Inside constructor
Caught exception!

Actual result:
--
Inside constructor
Inside destructor
Caught exception!






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

Req #43177 [Opn->Csd]: Errors in eval()'ed code produce status code 500

[stas]

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

 ID: 43177
 Updated by: s...@php.net
 Reported by:taneli at crasman dot fi
 Summary:Errors in eval()'ed code produce status code 500
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.2.4
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=86c46b96b6e93f566094917f0b24e79b795e062a
Log: add fix #43177


Previous Comments:

[2012-06-01 21:55:23] truth at proposaltech dot com

A fix is available in
https://github.com/jabouillei/php-src/tree/issue-43177

The changes are in main.c and zend.c.  github shows other files as being 
modified also, but that's probably from me not understanding part of the merge 
process.  My changes are in commit a65037ef46.


[2012-06-01 17:40:36] truth at proposaltech dot com

It's been over 4 years and the fix is known!  I can't believe I spent all day 
yesterday debugging this.  I was filing a bug report and the system found this 
match.  I'm using php 5.4.3.  I'll paste the rest of my notes into this comment 
because they include references to the documentation, updated line numbers, and 
other details not present in the original report.  Please commit a fix!  More 
and more people will hit this as more and more people use AJAX.
--- Description: ---
http://us2.php.net/manual/en/function.eval.php states:
If there is a parse error in the evaluated code, eval() returns FALSE and 
execution of the following code continues normally.

In reality, eval() can have the side effect of setting the response code to 500 
and leaving it at 500.  My guess is that this has gone unnoticed because 
everything else proceeds normally enough to produce an otherwise normal page 
and browsers are willing to display such pages even though the response code is 
500.  However, wget complains about the 500 and an AJAX framework that checks 
response codes may refuse to display the page.  I believe the point of 
continuing normally is that eval() should not ruin the current page.

I think the fix is to put
"&& EG(current_execute_data)->opline->extended_value != ZEND_EVAL"
into the "if" block at line 1132 of main.c.  The "if" decides whether to set 
the response code to 500 in the case of a parse error.

I just noticed the exit status is also modified by eval() a few lines earlier.  
Given the function description, it doesn't seem correct to force the exit 
status to 255.  I guess the same "if" applies.

I'm guessing it is redundant to make sure the type is E_PARSE in the the case 
of ZEND_EVAL, but someone how knows more about internals should probably 
confirm that.
--- Test script: ---

--- Expected result: ---
hello world

with exit code 0
--- Actual result ---
That looks good in a browser, but fails with wget (and my AJAX framework and 
anything else that relies on the response code).  On the command line, the exit 
code is 255.


[2007-11-05 11:06:51] holster at iki dot fi

A vote from me. Parse error in eval'ed code should not alter HTTP status 
(well, as long as one is not able to catch it).


[2007-11-02 11:43:10] taneli at crasman dot fi

Here's a patch for this issue:

--- php-5.2.4-vanilla/main/main.c   2007-11-01 15:20:37.0 +0200
+++ php-5.2.4/main/main.c   2007-11-01 17:26:45.0 +0200
@@ -957,11 +957,15 @@
if (!SG(headers_sent) &&
SG(sapi_headers).http_response_code == 
200
) {
-   sapi_header_line ctr = {0};
-
-   ctr.line = "HTTP/1.0 500 Internal 
Server Error";
-   ctr.line_len = strlen(ctr.line);
-   sapi_header_op(SAPI_HEADER_REPLACE, 
&ctr TSRMLS_CC);
+   if (!EG(current_execute_data) ||
+   
!EG(current_execute_data)->opline ||
+   
EG(current_execute_data)->opline->opcode != ZEND_INCLUDE_OR_EVAL) {
+   sapi_header_line ctr = {0};
+
+   ctr.line = "HTTP/1.0 500 
Internal Server Error";
+  

Bug #63463 [Opn->Nab]: ReflectionProperty::setValue and ::getValue trigger magic methods

[stas]

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

 ID: 63463
 Updated by: s...@php.net
 Reported by:ocramius at gmail dot com
 Summary:ReflectionProperty::setValue and ::getValue trigger
 magic methods
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reflection related
 Operating System:   Irrelevant
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

I am sorry, but I think your opinion is incorrect. Reflection works the same 
way and 
uses the same engine methods as other ways of accessing properties. Making 
Reflection work differently from the rest of the object model would require 
special 
exceptions in all object engine for Reflection and seems to make little sense 
to me 
in general. Reflection is just another way of doing the same thing as regular 
property access. I am sorry that your code does not work as you wanted it to, 
and 
you are welcome to propose ways to improve it, including participating in 
getters/setters discussion ongoing, but I do not think in this particular case 
reflection is doing something wrong. In any case, it is not a bug as the code 
is 
doing exactly as the intent of the code was for it to do.


Previous Comments:

[2012-12-10 02:04:46] ocramius at gmail dot com

@stas let me put it into a more "practical" use case I currently have:

I use reflection to populate instances of proxy objects that have "lazy" marked 
properties unset at instantiation time. This is good to achieve lazy loading of 
public properties, but any r/w access to the property itself via reflection 
triggers `__get` or `__set`.

This makes it impossible to use reflection to populate the property. I worked 
around it by disabling `__get` in particular situations (see 
https://github.com/Ocramius/common/blob/DCOM-96/lib/Doctrine/Common/Reflection/RuntimePublicReflectionProperty.php),
 but at a terrible cost in performance terms and broken behaviour in rare cases.

Back to the issue itself:

I consider Reflection as my last resource to access and modify status of 
objects without affecting anything else within my environment. Having 
reflection trigger any logic during an assignment is an unwanted and dangerous 
behaviour in my opinion.


[2012-12-10 01:51:32] s...@php.net

I'm not sure why you think this is what should be happening. When you unset 
properties, they are no longer set. And when you access unset properties, magic 
methods kick in. So where's the problem here?


[2012-11-08 06:22:43] ocramius at gmail dot com

I've added the failing test case as a PR at 
https://github.com/php/php-src/pull/230


[2012-11-08 06:15:03] ocramius at gmail dot com

Description:

When unset properties are requested, ReflectionProperty::setValue and 
ReflectionProperty::getValue trigger __get and __set magic methods.

Test script:
---
https://gist.github.com/4037155

Expected result:

The test script should report NULL for each of the requested values, and never 
call __set nor __get

Actual result:
--
__set and __get are called when ReflectionProperty tries to read or write to 
the requested properties.






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

Bug #63463 [Opn->Fbk]: ReflectionProperty::setValue and ::getValue trigger magic methods

[stas]

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

 ID: 63463
 Updated by: s...@php.net
 Reported by:ocramius at gmail dot com
 Summary:ReflectionProperty::setValue and ::getValue trigger
 magic methods
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reflection related
 Operating System:   Irrelevant
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

I'm not sure why you think this is what should be happening. When you unset 
properties, they are no longer set. And when you access unset properties, magic 
methods kick in. So where's the problem here?


Previous Comments:

[2012-11-08 06:22:43] ocramius at gmail dot com

I've added the failing test case as a PR at 
https://github.com/php/php-src/pull/230


[2012-11-08 06:15:03] ocramius at gmail dot com

Description:

When unset properties are requested, ReflectionProperty::setValue and 
ReflectionProperty::getValue trigger __get and __set magic methods.

Test script:
---
https://gist.github.com/4037155

Expected result:

The test script should report NULL for each of the requested values, and never 
call __set nor __get

Actual result:
--
__set and __get are called when ReflectionProperty tries to read or write to 
the requested properties.






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

Bug #63666 [Opn->Csd]: Poor date() performance [PATCH]

[stas]

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

 ID: 63666
 Updated by: s...@php.net
 Reported by:njaguar at gmail dot com
 Summary:Poor date() performance [PATCH]
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Performance problem
 Operating System:   any
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=fd650ec93e15bbbc05542e4acdde13d1fd9bcf73
Log: fix bug #63666 - Poor date() performance


Previous Comments:

[2012-12-02 00:50:20] njaguar at gmail dot com

Description:

Full info here:
http://news.php.net/php.internals/64127

4.4.9 on old machine vs 5.4.9 on new machine:
date: 1.856 sec date: 2.111 sec

after patch (~20% performance increase):
date: 1.763 sec

* new machine is 2 to 200x faster than old machine, see link above for more 
details


Test script:
---
// common date output format

// use any preferred timing methods either within php, or externally time 
execution of the script (eg, microtime(), etc) -- the former will be more 
accurate at isolating the date() function, overall
$c = 100;
for($i=0; $i<$c; $i++) date('F j, Y, g:i a', $now);


Expected result:

worse performance on stock builds, better when patch is applied -- still 
considerably slower than 4.4.9 version of date() and related, but is an 
improvement

Actual result:
--
By moving the frequently used iso fetching function into the switch statement, 
this prevents an otherwise unnecessary step for other more common usages of 
date formatting.






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

Bug #63641 [Asn->Csd]: imagepng and other save functions ignore streams

[stas]

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

 ID: 63641
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:imagepng and other save functions ignore streams
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:GD related
 Operating System:   *
 PHP Version:5.4.9
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

oops, my fault, it was 5.3 build, not 5.4. 5.4 works fine. Sorry for the noise.


Previous Comments:

[2012-11-28 23:11:51] s...@php.net

Description:

imagepng() and other functions that call _php_image_output() ignore PHP streams 
and instead call directly VCWD_FOPEN. This means that no streams work with 
these 
functions, and no handler that works within stream system works with this 
functions. Since most of the streams can be represented as FILE*, there's no 
reason not to use proper streams API instead of fopen. 







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

Req #63188 [Opn->Csd]: Display class name when debugging with gdb macro zbacktrace

[stas]

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

 ID: 63188
 Updated by: s...@php.net
 Reported by:re...@php.net
 Summary:Display class name when debugging with gdb macro
 zbacktrace
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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-09-30 17:54:20] re...@php.net

Hi Laruence,

1. Hmm, it is, if build with zts zbacktrace need running process,
   I know it's another problem:) dump_bt didn't before, that could be fixed
   I will update that to not require running process.

2. It would be easier to debug, such as test script, if there are inherent
   or the same function/method name, method's backtrace are the same as normal
   function. if there are class name, we will not need to check them one by 
one:)


[2012-09-30 15:51:45] larue...@php.net

1. it's not a good idea to make 'zbacktrace' require a running process.
2. and why need this? there are file/line/method already


[2012-09-29 19:22:04] re...@php.net

A patch was sent here: 
https://github.com/php/php-src/pull/209


[2012-09-29 19:17:14] re...@php.net

Description:

For example, an uncatched exception backtrace and debug_backtrace()
 have class name if it's an method. but when debugging with gdb,
the macro zbacktrace and dump_bt didn't display it.

it would be easier to debug if the class name displayed

just like:
Fatal error: Uncaught exception 'Exception' with message 'NO' in 
/Users/reeze/Opensource/php-test/php-src-5.4/b.php:5
Stack trace:
#0 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(9): A::bar()
#1 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(15): A->foo(1)
#2 /Users/reeze/Opensource/php-test/php-src-5.4/b.php(20): B->foo(1)
#3 {main}
  thrown in /Users/reeze/Opensource/php-test/php-src-5.4/b.php on line 5

Test script:
---
foo(1);


Expected result:

[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] A::bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] A->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] B->foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 

Actual result:
--
[0x100ca4490] core_me("127.0.0.1") /Users/reeze/Opensource/php-test/php-src-
5.4/b.php:5 
[0x100ca43a8] bar() /Users/reeze/Opensource/php-test/php-src-5.4/b.php:8 
[0x100ca42b8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:14 
[0x100ca40e8] foo(1) /Users/reeze/Opensource/php-test/php-src-5.4/b.php:19 






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

Bug #62561 [Opn->Csd]: DateTime add 'P1D' adds 25 hours

[stas]

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

 ID: 62561
 Updated by: s...@php.net
 Reported by:zach dot bailey at pardot dot com
 Summary:DateTime add 'P1D' adds 25 hours
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Mac OS X 10.7.4
 PHP Version:5.3.14
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

merged into 5.4


Previous Comments:

[2012-09-30 04:34:54] lonnyk at gmail dot com

A potential fix is available https://github.com/php/php-src/pull/210


[2012-09-30 00:50:22] lonnyk at gmail dot com

This seems to be related to bug #62896


[2012-09-29 02:32:09] lonnyk at gmail dot com

This bug is the result of the fix for bug #55253 and bug #60236


[2012-08-17 14:00:54] adam at lundrigan dot ca

Confirmed using PHP 5.3.16 (compiled from src) on RHEL 5.8

Failing PHPT test: 
https://github.com/adamlundrigan/php-src/blob/409bf5d69aa2889d910af1b8edfe159febae/ext/date/tests/bug62561.phpt


[2012-07-13 21:41:27] zach dot bailey at pardot dot com

Description:

When a DateTime is constructed with a non-UTC timezone and one day is added, 
the 
time also jumps forward by an hour as well.

Test script:
---
$ts = new DateTime('@1341115200', new DateTimeZone('America/New_York'));

$dayFromTs = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs->add(new DateInterval('P1D'));

echo 'ts: '.$ts->format('Y-m-d H:i:s')."\n";
echo 'day from ts: '.$dayFromTs->format('Y-m-d H:i:s')."\n";

Expected result:

ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 04:00:00

Actual result:
--
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 05:00:00






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

Bug #62896 [Opn->Csd]: "DateTime->modify('+0 days')" Modifies DateTime Object

[stas]

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

 ID: 62896
 Updated by: s...@php.net
 Reported by:hoang dot nguyen at groupion dot com
 Summary:"DateTime->modify('+0 days')" Modifies DateTime
 Object
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows, Linux
 PHP Version:5.4Git-2012-08-22 (snap)
-Assigned To:    
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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-09-30 00:49:29] lonnyk at gmail dot com

This seems to be related to bug #62561


[2012-08-22 15:30:30] hoang dot nguyen at groupion dot com

Description:

Calling "modify()" with a delta of 0 should not change the time, regardless of 
whether a time zone was defined for the DateTime object or not, and independent 
from how the object was created (from a UNIX timestamp or a date/time string 
with or without time zone).


Test script:
---
See long version with more details and possible regressions here: 
http://pastebin.com/v8RybhVh

Below is a short excerpt for the current bug.

format('Y-m-d H:i:s T').' (offset '.$date->getOffset().")\n";

  $date->modify('+0 days');
  echo $date->format('Y-m-d H:i:s T').' (offset '.$date->getOffset().")\n";
?>


Expected result:

FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+ (offset 0)  <-- should be equal
2012-08-21 22:00:00 GMT+ (offset 0)  <-- to this
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)


Actual result:
--
Output from PHP 5.4.4, 5.4.6 and snapshot r4e56105 from August 22, 2012:

FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+ (offset 0)  <-- different 
2012-08-21 23:00:00 GMT+ (offset 0)  <-- from this
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)

In PHP 5.2.0, the bug appears when creating DateTime from a string (with time 
zone), which one might test as well to guard against similar bugs:

FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+0100 (offset 7200)
2012-08-21 22:00:00 GMT+0100 (offset 7200)
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200)  <-- different
2012-08-21 23:00:00 CEST (offset 7200)  <-- from this







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

Req #63147 [Asn->Csd]: Some tests fail because require internet connection

[stas]

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

 ID: 63147
 Updated by: s...@php.net
 Reported by:r...@php.net
 Summary:Some tests fail because require internet connection
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:Testing related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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-09-27 06:58:32] paj...@php.net

Assigned to Remi. :)


[2012-09-25 04:57:23] r...@php.net

There is a few tests concerned and probably a few people affected.
But --offline option added (in the pull request)

Note : if this "small" feature is accepted, I will also check the non-standard 
extension for such tests (currently, with run "make test", after build, only 
for static extension)


[2012-09-25 03:10:30] larue...@php.net

remi, should there also be a corresponding option for run-test.php?


[2012-09-24 07:46:34] r...@php.net

See https://github.com/php/php-src/pull/201


[2012-09-24 07:04:36] r...@php.net

Description:

Hi,

Test which requires an internet connection (dns request, ...) fail if test are 
run offline.

This is the case in some build environment.

Proposal : add a SKIP_ONLINE_TESTS condition for such tests.

I will submit a pull request.







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

Bug #63162 [Opn->Csd]: parse_url does not matches password component

[stas]

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

 ID: 63162
 Updated by: s...@php.net
 Reported by:franssen dot roland at gmail dot com
 Summary:parse_url does not matches password component
-Status: Open
+Status: Closed
 Type:   Bug
 Package:URL related
 Operating System:   Ubuntu
 PHP Version:5.4.7
-Assigned To:
+Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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-09-25 19:18:48] franssen dot roland at gmail dot com

Description:

Password component is not matched if only the authority part is given... it 
does matches however if a scheme is provided with it.

Due the difference between example 2 and 3 i'm not sure if a relative URI 
reference is supported or not.

Test script:
---
http://user:pass@host'));
var_dump(parse_url('//user:pass@host'));
var_dump(parse_url('//user@host'));

Expected result:

array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(4) "host"
  ["user"]=>
  string(4) "user"
  ["pass"]=>
  string(4) "pass"
}
array(3) {
  ["host"]=>
  string(4) "host"
  ["user"]=>
  string(4) "user"
  ["pass"]=>
  string(4) "pass"
}
array(2) {
  ["host"]=>
  string(4) "host"
  ["user"]=>
  string(4) "user"
}


Actual result:
--
array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(4) "host"
  ["user"]=>
  string(4) "user"
  ["pass"]=>
  string(4) "pass"
}
array(1) {
  ["path"]=>
  string(16) "//user:pass@host"
}
array(2) {
  ["host"]=>
  string(4) "host"
  ["user"]=>
  string(4) "user"
}






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

Req #54564 [Opn]: extension_dir should be used for loading zend_extensions

[stas]

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

 ID: 54564
 Updated by: s...@php.net
 Reported by:tyra3l at gmail dot com
 Summary:extension_dir should be used for loading
 zend_extensions
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

I think loading extensions through relative path opens a way to all kinds of 
dangerous behavior and may have problematic security implications - like ones 
described here: http://arstechnica.com/information-technology/2010/08/new-
windows-dll-security-flaw-everything-old-is-new-again/. I'm not sure also why 
it 
is necessary - why can't PHP extension be installed in extension dir and run 
from 
there? If one needs multiple ones, multiple php.ini files can always be used.


Previous Comments:

[2011-04-18 23:05:25] tyra3l at gmail dot com

Description:

I've brought this topic on the internals
http://marc.info/?l=php-internals&m=130314285822279&w=2
and I think that it would be useful and more consistent, if this could be 
changed, 
so one could easily load both "normal" and zend extensions without the need to 
use 
absolute paths.


Test script:
---
php -n -d zend_extension=xdebug.so -r ''

Actual result:
--
Failed loading xdebug.so:  xdebug.so: cannot open shared object file: No such 
file 
or directory






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

Req #61421 [Asn->]: OpenSSL signature verification missing RMD160, SHA224, SHA256, SHA384, SHA512

[stas]

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

 ID: 61421
 Updated by: s...@php.net
 Reported by:mark at zedwood dot com
 Summary:OpenSSL signature verification missing RMD160,
 SHA224, SHA256, SHA384, SHA512
-Status: Assigned
+Status: To be documented
 Type:   Feature/Change Request
 Package:OpenSSL related
 Operating System:   Ubuntu Linux
 PHP Version:5.4.5
 Assigned To:pajoye
 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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-09-14 17:56:53] mark at zedwood dot com

PHP 5.4 release manager stas had me create a pull request for this bug.
https://github.com/php/php-src/pull/196


[2012-07-20 00:05:02] mark at zedwood dot com

updated version to php 5.4.5


[2012-06-27 06:21:58] paj...@php.net

Patch compiles fine, I asked the RMs if it is fine to merge into 5.3/4.

Will commit all at once once I got an answer.

Thanks for your work and patience!


[2012-06-21 20:14:04] mark at zedwood dot com

This issue is an important feature to add to PHP, considering
"SHA-1 has recently been demonstrated to provide less than 80 bits of security 
for digital signatures; at the publication of this Recommendation, the security 
strength against collisions is assessed at 69 bits. The use of SHA-1 is not 
recommended for the generation of digital signatures in new systems; new 
systems should use one of the larger hash functions. (SHA-224, SHA-256, SHA-384 
and SHA-512)"
https://wiki.mozilla.org/CA:MD5and1024


[2012-06-19 13:43:53] mark at zedwood dot com

Those new examples are also all be in the openssl-add-sig-algs.txt patch file I 
uploaded yesterday.  So we should be good to go.




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=61421


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

Bug #18556 [Csd]: Setting locale to 'tr_TR' lowercases class names

[stas]

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

 ID: 18556
 Updated by: s...@php.net
 Reported by:spud at nothingness dot org
 Summary:Setting locale to 'tr_TR' lowercases class names
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux (RedHat 7.2)
 PHP Version:5CVS, 4CVS (2005-10-04)
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

It looks like snaps is serving 5.4 under the name of php-trunk. Not sure why. 
Could you submid a website bug for that and send me the bug ID?
In the meantime you could use github: https://github.com/php/php-src just use 
the 
"zip file" option and you could build it from there.


Previous Comments:

[2012-09-13 15:31:04] richlv at nakts dot net

thanks for the response.

$ wget http://snaps.php.net/php-trunk-201209131330.tar.gz
$ wget http://snaps.php.net/php-trunk-201209131330.tar.bz2
$ wget http://snaps.php.net/php-trunk-201209131330.tar.xz

$ for type in gz bz2 xz; do mkdir $type; (cd $type; tar -xf 
../php-trunk-201209131330.tar.$type); done

$ grep "PHP_VERSION " {bz2,gz,xz}/php-trunk-201209131330/main/php_version.h
bz2/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"
gz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"
xz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION "5.4.8-dev"

is that ok for trunk snapshots then ?


[2012-09-10 06:22:46] s...@php.net

You should be using 5.5 (or master) branch of PHP. It is not fixed in 5.4 due 
to necessities of binary APIs change which is not possible in stable version. 
Trunk does not announce itself as 5.4 but as 5.5, so there must be some 
mistake. 

However if you feel very adventurous, you can take 5.5 commit (it's marked with 
the bug #) and cherry-pick it into your 5.4 branch.


[2012-09-08 14:54:04] richlv at nakts dot net

hmm, i just tested trunk snapshot php-trunk-201209081330 which announces itself 
as 5.4.8-dev

trying to use turkish locale still fails with :
Fatal error: Class 'CInput' not found

(there's uppercase I in the name)

what am i doing wrong ?


[2012-09-08 14:25:15] richlv at nakts dot net

which version is expected to have the fix ? looking at snapshots, is it trunk 
only (thus php 5.5 or whichever will be the next version) ?

interesting bit - this bug was fixed just 9 days short of it's 10th birthday ;)
(submitted 2002-07-25, fixed 2012-07-16)


[2012-07-16 14:21:36] me at ollieread dot com

I don't know how helpful this will be, but I've recently had an issue with the 
Turkish locale where I work.

I tried lots of different methods, but the main issue seems to be with 
LC_CTYPE, 
as although class/method declarations include I, it's added to the stack as i.

I've wrote a couple of fixes that hopefully approach all cases, be warned, they 
are however a bit hacky.

http://codeosaur.us/2012/07/16/php-and-the-tr_tr-utf8-locale/

You can simple explicitly set LC_CTYPE to your native language(eg en_US.utf8), 
but if you absolutely must have tr_TR.utf8 there, then you can use the magic of 
__autoload(), __call() and class_alias to handle it for you.

Hope this helps.




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=18556


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

Bug #18556 [Csd]: Setting locale to 'tr_TR' lowercases class names

[stas]

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

 ID: 18556
 Updated by: s...@php.net
 Reported by:spud at nothingness dot org
 Summary:Setting locale to 'tr_TR' lowercases class names
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux (RedHat 7.2)
 PHP Version:5CVS, 4CVS (2005-10-04)
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

You should be using 5.5 (or master) branch of PHP. It is not fixed in 5.4 due 
to necessities of binary APIs change which is not possible in stable version. 
Trunk does not announce itself as 5.4 but as 5.5, so there must be some 
mistake. 

However if you feel very adventurous, you can take 5.5 commit (it's marked with 
the bug #) and cherry-pick it into your 5.4 branch.


Previous Comments:

[2012-09-08 14:54:04] richlv at nakts dot net

hmm, i just tested trunk snapshot php-trunk-201209081330 which announces itself 
as 5.4.8-dev

trying to use turkish locale still fails with :
Fatal error: Class 'CInput' not found

(there's uppercase I in the name)

what am i doing wrong ?


[2012-09-08 14:25:15] richlv at nakts dot net

which version is expected to have the fix ? looking at snapshots, is it trunk 
only (thus php 5.5 or whichever will be the next version) ?

interesting bit - this bug was fixed just 9 days short of it's 10th birthday ;)
(submitted 2002-07-25, fixed 2012-07-16)


[2012-07-16 14:21:36] me at ollieread dot com

I don't know how helpful this will be, but I've recently had an issue with the 
Turkish locale where I work.

I tried lots of different methods, but the main issue seems to be with 
LC_CTYPE, 
as although class/method declarations include I, it's added to the stack as i.

I've wrote a couple of fixes that hopefully approach all cases, be warned, they 
are however a bit hacky.

http://codeosaur.us/2012/07/16/php-and-the-tr_tr-utf8-locale/

You can simple explicitly set LC_CTYPE to your native language(eg en_US.utf8), 
but if you absolutely must have tr_TR.utf8 there, then you can use the magic of 
__autoload(), __call() and class_alias to handle it for you.

Hope this helps.


[2012-07-14 22:59:37] s...@php.net

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 in master.


[2012-07-04 08:52:28] maar...@php.net

@ stormbyte, I just made 2 separate more explicit tests, one for 
tr_TR.iso8859-9 and one for tr_TR.UTF-8 and they do have the same outcome:

tr_TR.iso8859-9 - http://3v4l.org/o5YCk
tr_TR.UTF-8 - http://3v4l.org/F2gEb

3v4l.org uses a 'vanilla' PHP setup, be free to play with phpinfo() and the 
likes to see for yourself.




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=18556


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=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=60110&edit=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=revision&revision=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=60110&edit=1

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

[stas]

Edit report at https://bugs.php.net/bug.php?id=62844&edit=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=1&foo=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=62844&edit=1

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

[stas]

Edit report at https://bugs.php.net/bug.php?id=60097&edit=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('https://bugs.php.net/bug.php?id=60097&edit=1

Bug #40459 [ReO->Csd]: Stat and Dir stream wrapper methods do not call constructor

[stas]

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

 ID: 40459
 Updated by: s...@php.net
 Reported by:clay at killersoft dot com
 Summary:Stat and Dir stream wrapper methods do not call
 constructor
-Status: Re-Opened
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   irrelevant
 PHP Version:5.2.1
 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-09 07:12:26] s...@php.net

Automatic comment on behalf of stas
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=4db70fd406c805a296f4531088fe716a1ef67158
Log: fix bug #40459 - make all stream funcs that create object call ctor


[2012-08-07 23:48:41] s...@php.net

See also: https://github.com/php/php-src/pull/93


[2012-05-04 12:47:27] jschipp...@php.net

I believe this issue is still present. I have attached a test case to 
demonstrate the problem.

When looking at main/streams/userspace.c, it is clear that only in 
user_wrapper_opener() the constructor of the user space class is called (the 
"if (uwrap->ce->constructor) {}" block).


[2012-05-04 12:46:05] jschipp...@php.net

The following patch has been added/updated:

Patch Name: bug-40459
Revision:   1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459&patch=bug-40459&revision=1336135565


[2008-07-21 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=40459


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

Bug #40459 [ReO]: Stat and Dir stream wrapper methods do not call constructor

[stas]

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

 ID: 40459
 Updated by: s...@php.net
 Reported by:clay at killersoft dot com
 Summary:Stat and Dir stream wrapper methods do not call
 constructor
 Status: Re-Opened
 Type:   Bug
 Package:Streams related
 Operating System:   irrelevant
 PHP Version:5.2.1
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

See also: https://github.com/php/php-src/pull/93


Previous Comments:

[2012-05-04 12:47:27] jschipp...@php.net

I believe this issue is still present. I have attached a test case to 
demonstrate the problem.

When looking at main/streams/userspace.c, it is clear that only in 
user_wrapper_opener() the constructor of the user space class is called (the 
"if (uwrap->ce->constructor) {}" block).


[2012-05-04 12:46:05] jschipp...@php.net

The following patch has been added/updated:

Patch Name: bug-40459
Revision:   1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459&patch=bug-40459&revision=1336135565


[2008-07-21 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-13 15:56:45] 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




[2007-02-13 07:01:33] clay at killersoft dot com

Description:

The following methods in a userspace stream wrapper will not call the 
constructor:

url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()


Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt

Expected result:

Any time a line of output beginning with '== [method] CALLED' appears, that 
line should contain an 'obj: ' value with a uniqid value, indicating that the 
constructor was called.

Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...






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

Bug #54254 [Opn->Csd]: cal_from_jd returns month = 6 when there is only one Adar

[stas]

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

 ID: 54254
 Updated by: s...@php.net
 Reported by:asphp at dsgml dot com
 Summary:cal_from_jd returns month = 6 when there is only one
 Adar
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Calendar related
 PHP Version:5.3.5
-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 in master


Previous Comments:

[2012-03-29 18:33:50] asphp at dsgml dot com

woordengeschrift you misunderstand the Hebrew calendar.

In non-leap years there is a gap, the calendar months go: 4,5,7,8 - month 6 is 
skipped. Unfortunately PHP does 4,5,6,8 - it skips month 7 instead of 6 which 
is incorrect.

In a leap year it is AdarI that is added - AdarII is the same as Adar. Yes, I 
know you would expect the second one to be the "extra", but that's not how the 
calendar works.


[2012-03-29 12:13:03] info at woordengeschrift dot nl

In NON-leap years, there is only the unnumbered month of Adar.


[2012-03-29 12:09:41] info at woordengeschrift dot nl

In leap years, there is only the unnumbered month of Adar.
Numbered Adars only occur in leap years: Adar_I (the actual leap month),
followed by Adar_II.


[2011-03-15 09:53:50] asphp at dsgml dot com

Description:

cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 
7, since if there is only one Adar it's AdarII).

It also says "AdarI", which is wrong (it should be either "Adar" or at least 
"AdarII").

Furthermore the cal_days_in_month() (correctly) only works with month 7, and 
not 6 as returned by cal_from_jd.

Test script:
---



Expected result:

The month in cal_from_jd should be 7.

The second two lines demonstrate how cal_days_in_month also expects the month 
to be 7.

Actual result:
--
Array
(
[date] => 6/24/5772
[month] => 6
[day] => 24
[year] => 5772
[dow] => 0
[abbrevdayname] => Sun
[dayname] => Sunday
[abbrevmonth] => AdarI
[monthname] => AdarI
)
0
29







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

Bug #51363 [Csd]: Fatal error raised by var_export() not caught by error handler

[stas]

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

 ID: 51363
 Updated by: s...@php.net
 Reported by:daan at react dot com
 Summary:Fatal error raised by var_export() not caught by
 error handler
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian Etch
 PHP Version:5.2.13
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

Unfortunately, no good way to var_export recursive structures yet. You can use 
serialize() for that.


Previous Comments:

[2012-08-06 04:00:50] s...@php.net

fixed in 5.4 & trunk - var_export no longer produces fatal error but produces 
warning instead on recursion.


[2012-08-06 04:00:06] s...@php.net

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.




[2010-11-05 03:32:42] yohgaki at ohgaki dot net

I was biten by this bug recently.

Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not 
have protection against recursive arrays.

Therefore, zend_error() is raised in Zend Engine with E_ERROR. 
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible 
to catch exception or error by user error handler.

Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and 
raize E_NOTICE error for recursive dependency.

Since php_var_export() allows only one zval, export recursive dependency 
correctly by using '&'.


This bug is applicable to 5.2/5.3/trunk.


[2010-07-02 11:12:20] daan at react dot com

No I do not expect it to go on infinitely - the bug is that the php error 
caused by var_export() in this case is not caught by the error handler, when it 
should be.


[2010-04-22 22:37:22] whatrevolution at yahoo dot com

I am curious if the bug OP expects the var_export() output to never end... 
ever?  I do, because it is a recursive reference, so I'm puzzled that this is 
considered a bug.

However, perhaps the solution would be to not throw a fatal error, but throw a 
notice or warning and/or provide some way of telling var_export() how deep to 
print.

array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in 
/var/www/php_bugs/var_export_recursion_test.php on line 36

Call Stack
#   TimeMemory  FunctionLocation
1   0.0004  108776  {main}( )   ../var_export_recursion_test.php:0
2   0.0004  109968  var_export ( )  ../var_export_recursion_test.php:36


PHP Version 5.2.10-2ubuntu6.4

System  Linux 2.6.31-20-generic x86_64
Build Date  Jan 6 2010 22:36:47
Server API  Apache 2.0 Handler 
PHP API 20041225
PHP Extension   20060613
Zend Extension  220060519
Debug Build no
Thread Safety   disabled
Zend Memory Manager enabled 

Apache/2.2.12 (Ubuntu)




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=51363


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

Bug #51363 [Csd]: Fatal error raised by var_export() not caught by error handler

[stas]

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

 ID: 51363
 Updated by: s...@php.net
 Reported by:daan at react dot com
 Summary:Fatal error raised by var_export() not caught by
 error handler
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian Etch
 PHP Version:5.2.13
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

fixed in 5.4 & trunk - var_export no longer produces fatal error but produces 
warning instead on recursion.


Previous Comments:

[2012-08-06 04:00:06] s...@php.net

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.




[2010-11-05 03:32:42] yohgaki at ohgaki dot net

I was biten by this bug recently.

Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not 
have protection against recursive arrays.

Therefore, zend_error() is raised in Zend Engine with E_ERROR. 
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible 
to catch exception or error by user error handler.

Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and 
raize E_NOTICE error for recursive dependency.

Since php_var_export() allows only one zval, export recursive dependency 
correctly by using '&'.


This bug is applicable to 5.2/5.3/trunk.


[2010-07-02 11:12:20] daan at react dot com

No I do not expect it to go on infinitely - the bug is that the php error 
caused by var_export() in this case is not caught by the error handler, when it 
should be.


[2010-04-22 22:37:22] whatrevolution at yahoo dot com

I am curious if the bug OP expects the var_export() output to never end... 
ever?  I do, because it is a recursive reference, so I'm puzzled that this is 
considered a bug.

However, perhaps the solution would be to not throw a fatal error, but throw a 
notice or warning and/or provide some way of telling var_export() how deep to 
print.

array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in 
/var/www/php_bugs/var_export_recursion_test.php on line 36

Call Stack
#   TimeMemory  FunctionLocation
1   0.0004  108776  {main}( )   ../var_export_recursion_test.php:0
2   0.0004  109968  var_export ( )  ../var_export_recursion_test.php:36


PHP Version 5.2.10-2ubuntu6.4

System  Linux 2.6.31-20-generic x86_64
Build Date  Jan 6 2010 22:36:47
Server API  Apache 2.0 Handler 
PHP API 20041225
PHP Extension   20060613
Zend Extension  220060519
Debug Build no
Thread Safety   disabled
Zend Memory Manager enabled 

Apache/2.2.12 (Ubuntu)


[2010-03-23 12:58:59] daan at react dot com

Description:

When a fatal error is raised by var_export() when trying to export a resursive 
array, it is not caught by a user php error handler.

Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);

/* Don't execute PHP internal error handler */
return true;
}

set_error_handler("myErrorHandler");

$recursive = array();
$recursive[] = &$recursive; 

var_export($recursive);


Expected result:

The var_dumped variables

Actual result:
--
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array ( 
Fatal error: Nesting level too deep - recursive dependency? in test.php on line 
x







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

Bug #51363 [Asn->Csd]: Fatal error raised by var_export() not caught by error handler

[stas]

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

 ID: 51363
 Updated by: s...@php.net
 Reported by:daan at react dot com
 Summary:Fatal error raised by var_export() not caught by
 error handler
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Debian Etch
 PHP Version:5.2.13
 Assigned To:derick
 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:

[2010-11-05 03:32:42] yohgaki at ohgaki dot net

I was biten by this bug recently.

Not like php_var_dump() and php_debug_zval_dump(), php_var_export_ex() does not 
have protection against recursive arrays.

Therefore, zend_error() is raised in Zend Engine with E_ERROR. 
(HASH_PROTECT_RECURSION macro in zend_hash.c to be exact) This makes impossible 
to catch exception or error by user error handler.

Possible solutions:
Add recursion protection just like php_var_dump()/php_debug_zval_dump() and 
raize E_NOTICE error for recursive dependency.

Since php_var_export() allows only one zval, export recursive dependency 
correctly by using '&'.


This bug is applicable to 5.2/5.3/trunk.


[2010-07-02 11:12:20] daan at react dot com

No I do not expect it to go on infinitely - the bug is that the php error 
caused by var_export() in this case is not caught by the error handler, when it 
should be.


[2010-04-22 22:37:22] whatrevolution at yahoo dot com

I am curious if the bug OP expects the var_export() output to never end... 
ever?  I do, because it is a recursive reference, so I'm puzzled that this is 
considered a bug.

However, perhaps the solution would be to not throw a fatal error, but throw a 
notice or warning and/or provide some way of telling var_export() how deep to 
print.

array ( 0 => array ( 0 => array ( 0 => array ( 0 => array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in 
/var/www/php_bugs/var_export_recursion_test.php on line 36

Call Stack
#   TimeMemory  FunctionLocation
1   0.0004  108776  {main}( )   ../var_export_recursion_test.php:0
2   0.0004  109968  var_export ( )  ../var_export_recursion_test.php:36


PHP Version 5.2.10-2ubuntu6.4

System  Linux 2.6.31-20-generic x86_64
Build Date  Jan 6 2010 22:36:47
Server API  Apache 2.0 Handler 
PHP API 20041225
PHP Extension   20060613
Zend Extension  220060519
Debug Build no
Thread Safety   disabled
Zend Memory Manager enabled 

Apache/2.2.12 (Ubuntu)


[2010-03-23 12:58:59] daan at react dot com

Description:

When a fatal error is raised by var_export() when trying to export a resursive 
array, it is not caught by a user php error handler.

Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);

/* Don't execute PHP internal error handler */
return true;
}

set_error_handler("myErrorHandler");

$recursive = array();
$recursive[] = &$recursive; 

var_export($recursive);


Expected result:

The var_dumped variables

Actual result:
--
array ( 0 => array ( 0 => array ( 0 => array ( 0 => array ( 
Fatal error: Nesting level too deep - recursive dependency? in test.php on line 
x







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

Bug #62460 [Asn->Csd]: php binaries installed as binary.dSYM

[stas]

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

 ID: 62460
 Updated by: s...@php.net
 Reported by:phpbugs at adam dot gs
 Summary:php binaries installed as binary.dSYM
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:*Compile Issues
 Operating System:   OSX 10.8
 PHP Version:5.3.14
 Assigned To:johannes
 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-06 03:28:09] s...@php.net

Automatic comment on behalf of reeze@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=07ee764e5709dc8d9f26382d8e7438696f5bb834
Log: Fixed bug #62460 (php binaries installed as binary.dSYM)


[2012-07-20 02:55:21] reeze dot xia at gmail dot com

Hi, 
  The new released PHP-5.3.15 still have this bug. you could use the 
distributed tar package to reproduce.
using google to search php.dSYM there are a lot of result about it.

Thanks


[2012-07-19 06:45:26] larue...@php.net

johannes, could you please look at this? 

thanks


[2012-07-19 06:32:38] reeze dot xia at gmail dot com

Hi, 
  OSX 10.9 haven't exist at all, although *nix os didn't have any extension for
executable. but I'm ok with *darwin* match too.


[2012-07-18 17:56:00] phpbugs at adam dot gs

Perhaps we should just reduce that check to *darwin*? If not its just as likely 
to break again on 10.9, the *darwin* test seems much simpler in any event.


Interestingly I saw that line and though, "that's not it because it works on 
10.7 for me" I just retested and it DOES break on 10.7.




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=62460


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

Bug #61642 [Opn->Csd]: modify("+5 weekdays") returns Sunday

[stas]

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

 ID: 61642
 Updated by: s...@php.net
 Reported by:jeff at nd4c dot com
 Summary:modify("+5 weekdays") returns Sunday
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Fedora 14 and Windows 7
 PHP Version:Irrelevant
-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 in master


Previous Comments:

[2012-08-06 02:25:51] s...@php.net

Automatic comment on behalf of johnnysp...@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a6a7787cf25af0cf5b5672b677e20d9d40963137
Log: Fix #61642: modify("+5 weekdays") returns Sunday


[2012-04-11 16:11:26] jeff at nd4c dot com

The documentation is at:
http://www.php.net/manual/en/datetime.formats.relative.php

That page is linked to from:
http://www.php.net/manual/en/datetime.formats.php

Which is linked to from:
http://www.php.net/manual/en/datetime.modify.php


[2012-04-11 15:56:41] zhanglijiu at gmail dot com

I check the php manual, there is no weekdays parameter for modify. So you have 
to 
use modify(+ n day) or modify(+ n week).


[2012-04-05 18:01:12] jeff at nd4c dot com

Description:

Tested on Windows 7: 
  Apache/2.2.16 (Win32) PHP/5.3.5
Tested on Fedora 14: 
  Fedora release 14 (Laughlin) Linux 2.6.35.4-rscloud x86_64 
  php.x86_64 5.3.8-3.fc14
These are the latest stable versions I can find for these two systems.  
(Especially since V6 binaries are no longer available for Windows.)
The Linux system is a live server using a framework that has not been tested 
with any later versions than 5.3.8

When modifying a DateTime instance with "+5 weekdays" it will return a date for 
a Sunday and not a weekday.

Running the Test script you note that the section for "5" returns Sunday.  All 
the other numbers are correct.  Note the pattern for skipping the weekends is 
always for Friday, Saturday and Sunday.  However for "+5" weekends should be 
skipped for Saturday, Sunday and Monday, which is different than for any other 
number.

Test script:
---
$days = array(1,2,3,4,5,6,7,8,);
$dates = 
array('2012-03-29','2012-03-30','2012-03-31','2012-04-01','2012-04-02','2012-04-03','2012-04-04','2012-04-05',);
foreach ($days as $businessdays)
{
foreach ($dates as $startdate)
{
$start = new DateTime($startdate);
$date = new DateTime($startdate);
echo ''.$businessdays.' : '.$date->format('l').' : 
'.$date->format('Y-m-d');
$date->modify("+{$businessdays} weekdays");
echo ' : '.$date->format('Y-m-d').' : '.$date->format('l');
}
echo '';
}



Expected result:

...

5 : Thursday : 2012-03-29 : 2012-04-05 : Thursday
5 : Friday : 2012-03-30 : 2012-04-06 : Friday
5 : Saturday : 2012-03-31 : 2012-04-09 : Monday
5 : Sunday : 2012-04-01 : 2012-04-09 : Monday
5 : Monday : 2012-04-02 : 2012-04-09 : Monday
5 : Tuesday : 2012-04-03 : 2012-04-10 : Tuesday
5 : Wednesday : 2012-04-04 : 2012-04-11 : Wednesday
5 : Thursday : 2012-04-05 : 2012-04-12 : Thursday

...

Actual result:
--
...

5 : Thursday : 2012-03-29 : 2012-04-05 : Thursday
5 : Friday : 2012-03-30 : 2012-04-08 : Sunday
5 : Saturday : 2012-03-31 : 2012-04-08 : Sunday
5 : Sunday : 2012-04-01 : 2012-04-08 : Sunday
5 : Monday : 2012-04-02 : 2012-04-09 : Monday
5 : Tuesday : 2012-04-03 : 2012-04-10 : Tuesday
5 : Wednesday : 2012-04-04 : 2012-04-11 : Wednesday
5 : Thursday : 2012-04-05 : 2012-04-12 : Thursday

...






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

Req #10203 [Wfx->Opn]: allow foreach($array as list($a,$b)

[stas]

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

 ID: 10203
 Updated by: s...@php.net
 Reported by:jack at mobil dot cz
 Summary:allow foreach($array as list($a,$b)
-Status: Wont fix
+Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:*
 Assigned To:laruence
 Block user comment: N
 Private report: N



Previous Comments:

[2011-08-19 11:57:44] larue...@php.net

since the RFC didn't win the vote, change the status to suspended.


[2011-07-06 08:15:55] larue...@php.net

The following patch has been added/updated:

Patch Name: php-5.4.0svn-add-foreach-list-support.patch
Revision:   1309954555
URL:
https://bugs.php.net/patch-display.php?bug=10203&patch=php-5.4.0svn-add-foreach-list-support.patch&revision=1309954555


[2011-07-06 01:35:43] larue...@php.net

I am working on this now, add firsh patch is submitted.


[2011-07-06 01:34:10] larue...@php.net

The following patch has been added/updated:

Patch Name: php-5.4.0-alpha1-foreach-list-diff.patch
Revision:   1309930450
URL:
https://bugs.php.net/patch-display.php?bug=10203&patch=php-5.4.0-alpha1-foreach-list-diff.patch&revision=1309930450


[2002-01-29 04:19:59] yohg...@php.net

It's in TODO already :)
Someone might implement it, but I guess it's not anytime soon.




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=10203


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

Bug #62462 [Opn->Fbk]: quoted_printable_encode splits line in the middle of UTF8 character

[stas]

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

 ID: 62462
 Updated by: s...@php.net
 Reported by:c2h5oh at poczta dot fm
 Summary:quoted_printable_encode splits line in the middle of
 UTF8 character
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*Mail Related
 Operating System:   Linux
 PHP Version:5.3.14
 Block user comment: N
 Private report: N

 New Comment:

The quoted bug is Thunderbird issue that produces real linebreak - note the 
absence of = at the end of line here:


=CE=B1=CE=B1=CE=B1=CE=B1=CE=B1=CE=B1=CE  <--- ERROR

instead of soft breaks. Clearly, this is a bug since the encoder should not 
insert hard line breaks. PHP produces soft breaks, which is in full compliance 
with the standard. 
I'm not sure also how RFC quote is relevant - if some clients/agents break the 
email text, we can't really be responsible for them and if they do that, they 
break QP encoding and something else - like base64 - should be used. I don't 
see 
however why it makes PHP's way of encoding be wrong.

Could you describe the scenario where the way PHP does things lead to something 
breaking, which is not due to bug in some other product? I also read 
swiftmailer 
report and also couldn't find description of any scenario where PHP encoding is 
wrong.


Previous Comments:

[2012-07-15 12:02:06] c2h5oh at poczta dot fm

>From RFC 2045:
"Because quoted-printable data is generally assumed to be line-
   oriented, it is to be expected that the representation of the breaks
   between the lines of quoted-printable data may be altered in
   transport, in the same manner that plain text mail has always been
   altered in Internet mail when passing between systems with differing
   newline conventions."

We have no guarantee that it will be possible to merge split character during 
decoding.

This has caused problems before: https://bugzilla.mozilla.org/show_bug.cgi?
id=684508
It's a problem widespread enough that for example SwiftMailer doesn't use 
quoted_printable_encode, but own PHP 
implementation which is more than an order of magnitude slower ( 
https://github.com/swiftmailer/swiftmailer/issues/220 ).

76 characters per line is the upper limit - adding soft line break earlier 
produces perfectly valid encoding that doesn't 
cause such problems.


[2012-07-15 02:31:30] s...@php.net

Could you explain why soft line breaks is a problem? The software decoding the 
QP 
string should ignore the linebreaks and reassemble the string in the original 
form. Quoting from https://en.wikipedia.org/wiki/Quoted-printable:

A soft line break consists of an "=" at the end of an encoded line, and does 
not 
appear as a line break in the decoded text. 

So where the corruption of the utf-8 comes from?


[2012-07-02 11:42:51] c2h5oh at poczta dot fm

Description:

quoted_printable_encode adds, among other things, soft line breaks if line 
lenght 
is greater than 76 characters. 
If that 76th character happens to be in the middle if encoded UTF8 character 
then 
this character will be split into two lines corrupting the encoded sting.



Test script:
---
https://bugs.php.net/bug.php?id=62462&edit=1