Bug #64157 [Opn->Csd]: DateTime::createFromFormat() reports confusing error message

[dsp]

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

 ID: 64157
 Updated by: d...@php.net
 Reported by:thefox at neonus dot sk
 Summary:DateTime::createFromFormat() reports confusing error
 message
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux
 PHP Version:5.3.21
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of dsp
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=c0afe829e33c5f5690c6967a102148984836d5aa
Log: News for bugfix #64157


Previous Comments:

[2013-02-05 14:09:44] thefox at neonus dot sk

Description:

Parsing invalid, single-digit input, for seconds using the 's' format reports 
confusing and incorrect error message: "A two second minute could not be found" 
caused probably by copying the error message for minutes ("A two digit minute 
could not be found") but replacing wrong word with "second".

Actually experienced in 5.3.10 but the error message is present also in the 
source code for 5.3.21 (I can't get my hands on this version).

Test script:
---
 A two digit second could not be found
)

Actual result:
--
Array
(
[0] => A two second minute could not be found
)






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

Bug #64441 [Asn->Csd]: FILTER_VALIDATE_URL rejects fully qualified domain names

[dsp]

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

 ID: 64441
 Updated by: d...@php.net
 Reported by:phpwnd at gmail dot com
 Summary:FILTER_VALIDATE_URL rejects fully qualified domain
 names
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Filter related
 PHP Version:5.5.0alpha5
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of syr...@gmail.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=18b54a2366dd589959240f8770bbb54be819f6e7
Log: Fix bug #64441 (FILTER_VALIDATE_URL rejects fully qualified domain names)


Previous Comments:

[2013-03-16 22:25:42] phpwnd at gmail dot com

Description:

FILTER_VALIDATE_URL rejects fully qualified domain names even though 
parse_url() parses them just fine.

Test script:
---
var_dump(filter_var('http://example.com.', FILTER_VALIDATE_URL));

Expected result:

string(18) "http://example.com.";

Actual result:
--
bool(false)






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

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

[dsp]

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

 ID: 63520
 Updated by: d...@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:

I'd be more than happy to see a json extension drop-in. Obviously we cannot 
change the license without the authors permissions, so a drop-in would be the 
best approach.


Previous Comments:

[2013-08-28 09:20:59] paj...@php.net

Besides the license issue, which is a problem but not a php one, Remi's new 
extension brings its lot of nice new stuff.

Please leave this open and add a link to the new extension and RFC, to avoid 
endless confusion here.


[2013-08-28 08:02:41] r...@php.net

This issue need to be discussed by all PHP developers.

I plan to submit a RFC in a few days.
This bug will be closed according to the vote result.


[2013-08-28 07:51:20] r...@php.net

Keep this open.


[2013-08-28 07:39:35] ses...@php.net

Why do you guys even argue about this?

This is not a problem of PHP. It is a problem of Debian. If they don't like the 
license then they can just replace the code. Or they can go forward and drop 
the 
whole PHP package from their distribution. (Which is the usual threat from 
Debian 
mainteiners.)

Not a bug in PHP.


[2013-08-28 06:46:41] ond...@php.net

Stas: Of course it's a PHP bug.  PHP don't live in a vacuum, but has thriving 
ecosystem of various users/packagers/distributors/distributions/etc. and they 
are 
all affected by the choice you (as PHP) make.

It's not healthy to dug the head into the sand and pretend that it's not a 
_PHP_ 
bug, since it affects the users of PHP.




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 #65029 [Opn->Fbk]: Crash with phpinfo();

[dsp]

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

 ID: 65029
 Updated by: d...@php.net
 Reported by:paj...@php.net
 Summary:Crash with phpinfo();
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Windows
 PHP Version:5.5.0RC3
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2013-06-13 12:01:49] paj...@php.net

Not sure why yet, but accel_shared_globals is not initialized at all for the 
process where the crash occurs.


[2013-06-13 11:59:38] paj...@php.net

Forgot to mention, using fcgi (but should happen in TS too, I suspect)


[2013-06-13 11:58:46] paj...@php.net

Description:

Using current 5.5 branch:

http://127.0.0.1:8080/inf.php

crashes:

php_opcache.dll!accel_startup(_zend_extension * extension=0x00f429b8) Line 2525 
C
php5_debug.dll!zend_extension_startup(_zend_extension * extension=0x00f429b8) 
Line 154C
php5_debug.dll!zend_llist_apply_with_del(_zend_llist * l=0x534b5aa0, int (void 
*) * func=0x530da620) Line 178  C
php5_debug.dll!zend_startup_extensions(...) Line 175C
php5_debug.dll!php_module_startup(_sapi_module_struct * sf=0x010e8000, 
_zend_module_entry * additional_modules=0x010e80a0, unsigned int 
num_additional_modules=1) Line 2209 C
php-cgi.exe!php_cgi_startup(_sapi_module_struct * sapi_module=0x010e8000) Line 
936 C
php-cgi.exe!main(int argc=1, char * * argv=0x00f39400) Line 1910C
php-cgi.exe!__tmainCRTStartup() Line 536C
php-cgi.exe!mainCRTStartup() Line 377   C
kernel32.dll!@BaseThreadInitThunk@12() Unknown
ntdll.dll!___RtlUserThreadStart@8()Unknown
ntdll.dll!__RtlUserThreadStart@8() Unknown








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

Bug #64984 [Opn->Fbk]: Coredump by zend_signal_handler

[dsp]

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

 ID: 64984
 Updated by: d...@php.net
 Reported by:paulgao at yeah dot net
 Summary:Coredump by zend_signal_handler
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Centos 6.4
 PHP Version:5.5.0RC3
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2013-06-07 06:19:45] paulgao at yeah dot net

Description:

coredump When I use php-fpm and restart.

Test script:
---
php-fpm restart

Expected result:

normal restart.

Actual result:
--
coredump!

(gdb) bt
#0  0x7ffd9b1548a5 in raise () from /lib64/libc.so.6
#1  0x007525aa in zend_signal_handler (signo=3, siginfo=, context=0x7fff4c3b9840) at 
/root/php-5.5.0RC3/Zend/zend_signal.c:175
#2  0x007526ab in zend_signal_handler_defer (signo=3, 
siginfo=0x7fff4c3b9970, context=0x7fff4c3b9840) at 
/root/php-5.5.0RC3/Zend/zend_signal.c:86
#3  
#4  0x7ffd9b20b4b0 in __accept_nocancel () from /lib64/libc.so.6
#5  0x007dd511 in fcgi_accept_request (req=0x7fff4c3b9e50) at 
/root/php-5.5.0RC3/sapi/fpm/fpm/fastcgi.c:807
#6  0x007e4c0d in main (argc=, argv=) at /root/php-5.5.0RC3/sapi/fpm/fpm/fpm_main.c:1860






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

Bug #65108 [Opn->Csd]: is_callable() triggers Fatal Error

[dsp]

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

 ID: 65108
 Updated by: d...@php.net
 Reported by:miloslav dot hula at gmail dot com
 Summary:is_callable() triggers Fatal Error
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 PHP Version:5.5Git-2013-06-24 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of dsp
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=ecd9d7625098bfc0a14ffa1fc39535848e71fc80
Log: Fix #65108 (is_callable() triggers Fatal Error)


Previous Comments:

[2013-06-24 10:01:34] miloslav dot hula at gmail dot com

I'm sorry. I forgot to add the Fatal Error message.

Fatal error: Call to private method C::f() from context '' in 
/home/milo/fat.php on line 8


[2013-06-24 09:55:49] miloslav dot hula at gmail dot com

Description:

A Fatal Error is emmited when using is_callable() in static context on class 
with defined the __call() method and non-public non-static method 
simultaneously.

Similar to https://bugs.php.net/bug.php?id=33455.

Test script:
---
class C {
private function f() {}
function __call($name, $args) {}
}

$isCallable = is_callable(array('C', 'f'));

Expected result:

$isCallable is boolean

Actual result:
--
Fatal Error






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

Req #64826 [Opn->Nab]: Important error

[dsp]

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

 ID: 64826
 Updated by: d...@php.net
 Reported by:coolcool1994 at gmail dot com
 Summary:Important error
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Mac
 PHP Version:5.5Git-2013-05-12 (Git)
 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




Previous Comments:

[2013-05-14 12:09:00] anon at anon dot anon

Is there a particular language edition of the manual you're referring to? 
Because it looks fine to me.


[2013-05-12 21:20:46] coolcool1994 at gmail dot com

Description:

---
>From manual page: http://www.php.net/function.strstr#refsect1-function.strstr-
examples
---

strrchr should be used for the first example instead. Because strrstrr only 
catches the first occurance of the letter from the beginning of the string. 
strrchr should be used to find the first occurance of the letter from the end 
of 
the string.

Test script:
---
I tested but I do not have it here.

Expected result:

It is a common sense. Fix it!

Actual result:
--
It is a common sense. Fix it!






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

Bug #64833 [Opn->Asn]: ext/sockets/sendrecvmsg.c related compilation errors

[dsp]

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

 ID: 64833
 Updated by: d...@php.net
 Reported by:clicky at erebot dot net
 Summary:ext/sockets/sendrecvmsg.c related compilation errors
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Debian Squeeze
 PHP Version:5.5.0RC1
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N



Previous Comments:

[2013-05-13 21:49:36] clicky at erebot dot net

Description:

While trying to build PHP 5.5.0RC1 under Debian Squeeze, the following 
compilation errors were triggered.

I think this may be related to this commit that introduced support for 
SCM_CREDENTIALS and other goodies in the sockets extension recently: 
http://git.php.net/?p=php-src.git;a=commitdiff;h=a85d7f28f69fbc522ed90aee1926d3733be7620d

Also, please note that the manpage for UNIX sockets states that "struct ucred" 
(which is used in the code) is only defined when the _GNU_SOURCE macro is 
defined since glibc 2.8 [1]. This may also be the reason why the build fails 
(Debian Squeeze uses libc6-2.13 [2]).

Other projects have been impacted by this issue too [3].

[1] http://manpages.ubuntu.com/manpages/karmic/en/man7/unix.7.html
[2] http://packages.debian.org/wheezy/libc6
[3] http://sourceforge.net/p/wide-dhcpv6/bugs/29/ (also contains link to a 
glibc commit that changed some of the structs like in6_pktinfo to be 
macro-guarded).

Test script:
---
'./configure' \
'--enable-debug' \
'--disable-all' \
'--disable-short-tags' \
'--disable-sigchild' \
'--with-layout=GNU' \
'--with-regex' \
'--with-openssl=shared' \
'--with-zlib=shared' \
'--enable-bcmath=shared' \
'--with-bz2=shared' \
'--enable-calendar=shared' \
'--with-gettext=shared' \
'--enable-mbstring=shared' \
'--enable-pcntl=shared' \
'--enable-sockets=shared' \
'--with-pdo-sqlite' \
'--enable-sysvmsg=shared' \
'--enable-sysvsem=shared' \
'--enable-sysvshm=shared' \
'--with-xsl=shared' \
'--with-iconv=shared' \
'--enable-zip=shared' \
'--enable-posix=shared' \
'--enable-libxml=shared' \
'--enable-dom=shared' \
'--enable-xml=shared' \
'--enable-xmlreader=shared' \
'--enable-xmlwriter=shared' \
'--enable-tokenizer=shared' \
'--enable-pdo' \
'--enable-ctype=shared' \
'--enable-json=shared' \
'--enable-session=shared' \
'--enable-soap=shared' \
'--enable-simplexml=shared' \
'--enable-hash' \
'--enable-intl=shared' \
'--enable-phar=shared' \
'--with-sqlite3' \
'--with-mysql=shared,mysqlnd' \
'--with-mysqli=shared,mysqlnd' \
'--with-pdo-mysql=shared,mysqlnd' \
'--prefix=/home/qa/phpfarm/inst/php-5.5.0RC1-debug' \
'--exec-prefix=/home/qa/phpfarm/inst/php-5.5.0RC1-debug' \
'--without-pear' \
'--enable-cgi' \
'--enable-cli' \
'--enable-fpm' \
"$@"

(but could probably be reduced to just ./configure --disable-all 
--enable-sockets=shared)

Expected result:

PHP should build without any compilation error.

Actual result:
--
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c: In function 
‘init_ancillary_registry’:
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:109:2: error: 
invalid application of ‘sizeof’ to incomplete type ‘struct in6_pktinfo’
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:124:2: error: 
invalid application of ‘sizeof’ to incomplete type ‘struct ucred’
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:124:2: error: 
‘SCM_CREDENTIALS’ undeclared (first use in this function)
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:124:2: note: 
each undeclared identifier is reported only once for each function it appears in
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c: In function 
‘php_do_setsockopt_ipv6_rfc3542’:
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:339:12: 
error: invalid application of ‘sizeof’ to incomplete type ‘struct 
in6_pktinfo’
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:345:19: 
error: invalid application of ‘sizeof’ to incomplete type ‘struct 
in6_pktinfo’
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c: In function 
‘php_do_getsockopt_ipv6_rfc3542’:
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:377:17: 
error: invalid application of ‘sizeof’ to incomplete type ‘struct 
in6_pktinfo’
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c: In function 
‘php_socket_sendrecvmsg_init’:
/home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:436:2: error: 
‘SCM_CREDENTIALS’ undeclared (first use in this function)
make: *** [ext/sockets/sendrecvmsg.lo] Error 1







-- 
Edit this 

Bug #64712 [Opn->Csd]: Obsolete declarations in php_date.c

[dsp]

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

 ID: 64712
 Updated by: d...@php.net
 Reported by:s...@php.net
 Summary:Obsolete declarations in php_date.c
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux
 PHP Version:5.5.0beta4
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of dsp
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=75cec90d8cc2ea34ab9e5e7146cb6b3bf29430a9
Log: Fix #64712 (Obsolete declarations in php_date.c)


Previous Comments:

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

Description:

There are a couple of obsolete declarations in php_date.c:

/home/cjones/Desktop/php-5.5.0beta4/ext/date/php_date.c:617:26: warning: 
‘date_object_new_immutable’ declared ‘static’ but never defined 
[-Wunused-
function]
/home/cjones/Desktop/php-5.5.0beta4/ext/date/php_date.c:623:26: warning: 
‘date_object_clone_immutable’ declared ‘static’ but never defined 
[-Wunused-
function]








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

Bug #64711 [Opn->Csd]: "value computed but not used" in parse_date.c

[dsp]

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

 ID: 64711
 Updated by: d...@php.net
 Reported by:s...@php.net
 Summary:"value computed but not used" in parse_date.c
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux
 PHP Version:5.5.0beta4
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of dsp
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b86c85723ed0dfec8197821ecb9e5dc84c3dd1f7
Log: Fix #64711 ("value computed but not used" in parse_date.c)


Previous Comments:

[2013-04-25 18:21:12] s...@php.net

Description:

The "*ptr++" in parse_date.re:2099 results in the compilation warning:

/home/cjones/Desktop/php-5.5.0beta4/ext/date/lib/parse_date.c: In function 
‘timelib_parse_from_format’:
/home/cjones/Desktop/php-5.5.0beta4/ext/date/lib/parse_date.c:24994:5: warning: 
value computed is not used [-Wunused-value]

I guess the code should have been simply "fptr++".







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

Bug #64373 [Opn->Csd]: Compilation failure when building with --enable-maintainer-zts

[dsp]

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

 ID: 64373
 Updated by: d...@php.net
 Reported by:loic dot frering at gmail dot com
 Summary:Compilation failure when building with
 --enable-maintainer-zts
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Ubuntu 12.04 64bits
 PHP Version:5.5.0alpha5
-Assigned To:
+Assigned To:    dsp
 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-03-07 10:11:10] loic dot frering at gmail dot com

Description:

Building PHP 5.5.0alpha5 with --enable-maintainer-zts option leads to:

source/5.5.0alpha5/Zend/zend_language_parser.h:331:5: error: conflicting 
types for 'zendparse'
source/5.5.0alpha5/Zend/zend_globals_macros.h:35:5: note: previous 
declaration of 'zendparse' was here
make: *** [ext/standard/basic_functions.lo] Error 1

For information, I had no problem building 5.5.0alpha4 with the exact same 
options.







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

Bug #64253 [Opn->Fbk]: alpha 5 does not load extensions

[dsp]

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

 ID: 64253
 Updated by: d...@php.net
 Reported by:bugzilla77 at gmail dot com
 Summary:alpha 5 does not load extensions
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Dynamic loading
 Operating System:   win 7 32
 PHP Version:5.5.0alpha4
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2013-02-22 20:52:33] bugzilla77 at gmail dot com

Thanks - now it works.


[2013-02-22 00:58:05] szar...@php.net

Thanks for reporting this.  We narrowed this down to a build issue with the ZTS 
build of PHP-5.5.0alpha5.  I have fixed the issue and updated the build and 
checksum on http://windows.php.net/qa.  Can you please test the new build and 
let me know if it fixes the issue?

Thanks,
Steve


[2013-02-20 19:57:36] bugzilla77 at gmail dot com

I have TS and:

;extension=php_bz2.dll
extension=php_com_dotnet.dll
;extension=php_curl.dll
;extension=php_fileinfo.dll
extension=php_gd2.dll
;extension=php_gettext.dll
;extension=php_gmp.dll
;extension=php_intl.dll
;extension=php_imap.dll
;extension=php_interbase.dll
;extension=php_ldap.dll
extension=php_mbstring.dll
;extension=php_exif.dll  ; Must be after mbstring as it depends on it
;extension=php_mysql.dll
;extension=php_mysqli.dll
;extension=php_oci8.dll  ; Use with Oracle 10gR2 Instant Client
;extension=php_oci8_11g.dll  ; Use with Oracle 11gR2 Instant Client
;extension=php_openssl.dll
;extension=php_pdo_firebird.dll
;extension=php_pdo_mysql.dll
;extension=php_pdo_oci.dll
;extension=php_pdo_odbc.dll
;extension=php_pdo_pgsql.dll
;extension=php_pdo_sqlite.dll
;extension=php_pgsql.dll
;extension=php_pspell.dll
;extension=php_shmop.dll

; The MIBS data available in the PHP distribution must be installed. 
; See http://www.php.net/manual/en/snmp.installation.php 
;extension=php_snmp.dll

;extension=php_soap.dll
;extension=php_sockets.dll
;extension=php_sqlite3.dll
;extension=php_sybase_ct.dll
;extension=php_tidy.dll
;extension=php_xmlrpc.dll
;extension=php_xsl.dll
;extension=php_zip.dll


and a have not loaded php_com_dotnet.dll, php_mbstring.dll etc

On php 5.5 aplpha 4 is ok with the same php.ini


[2013-02-20 19:34:05] mattfic...@php.net

Extensions are fine for me with 5.5.0a5-NTS on Windows7, but the following 
extensions are missing on 5.5.0a5-TS:
bz2
exif
fileinfo
gd
gettext
imap
intl
mysql
mysqli
pdo_mysql
pdo_pgsql
pgsql
openssl
soap
wddx
xmlrpc

The TS and NTS builds of 5.4.12 and 5.3.22 all have all the extensions though 
(so its only a 5.5.0a5-TS problem).


[2013-02-20 16:57:01] bugzilla77 at gmail dot com

Description:

alpha 5 does not load extensions

Expected result:

alpha 4 loads extensions on the same php.ini

Actual result:
--
alpha 5 does not load extensions






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

Req #48358 [Asn->Csd]: SplDoublyLinkedList needs an insertAfterIterator() method or something similar

[dsp]

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

 ID: 48358
 Updated by: d...@php.net
 Reported by:dannel at aaronexodus dot com
 Summary:SplDoublyLinkedList needs an insertAfterIterator()
 method or something similar
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:SPL related
 PHP Version:5.3.0RC2
 Assigned To:colder
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of mba...@inviqa.com
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=42574690795937290a4ad6d319f917c077542953
Log: Fix #48358 add() method for SplDoublyLinkedLis


Previous Comments:

[2012-11-29 14:13:27] col...@php.net

It is not as easy as one might think.

The state of iterators are separated from the state of the list itself. This 
allows for multiple concurrent iterations on the same list but it complicates 
the issue at hand.

I see four viable alternatives (example for insertAfter):
  - SplDoublyLinkedList::insertAfter(value)   -- O(1), but would work 
only for explicit iteration using Iterator methods, not foreach()! which works 
using a fresh iterator.
  - SPLDoublyLinkedList::insertAfter(index, value)-- O(n), not exactly what 
we want but could be working.
  - SPLDoublyLinkedList::insertAfter(iterator, value) -- O(1), needs validation 
of the iterator itself.
  - SplDoublyLinkedList generates iterators of the class 
SplDoublyLinkedListIterator, which define a insertAfter(value), would require 
SplDLL to be an IteratorAggregate instead of Iterator.

Those are not mutually exclusive, but alternative #1 or #3 seem the most useful 
.

Note that while traversing elements should be easily doable, since list 
elements are ref-counted, the key() of iterators might return inconsistent 
results if you allow the middle of the 
lists to be expanded/reduced. Making it consistent would make it O(n), so it's 
probably not a big problem to keep it that way.


[2012-11-29 11:00:49] rdo...@php.net

I'm also running into this, usual implementations of DoublyLinkedList describe 
the 
insertBefore and insertAfter methods, wondering why they were left out in this 
implementation.


[2012-11-01 00:57:12] dnwake at gmail dot com

This is ridiculous.  

Efficiency of inserting and deleting in the middle of the list is the main 
motivation for using a linked list in the first place.


[2011-04-15 21:23:51] omercan at gmail dot com

O(n) complexity should be expected from a list data structure along with no 
array access. The drawback of lists is they lack direct access to the elements 
by their position. Well, that's not the case with SplDoublyLinkedList because 
there's array access. So, it's a different implementation as far as it seems.

In my opinion, the problem with SplDoublyLinkedList is that the main operations 
are left to be implemented in the user land, which require iterating over the 
list in each. This class can be much more valuable if the following operations 
are included:

clear() -> clear all elements

remove($value) -> return number of removals b/c $value can be more than 1

sort(Closure $predicate) -> sort without keeping key association

swap($list) -> swap with another list or a Traversable instance

unique() -> return the unique values in the list, possibly in a new list


[2010-05-22 13:46:01] 1000235409 at smail dot shnu dot edn dot cn

i have encountered the same problem today, after this was modified for 1 year...

but i have a solution to solve this problem. write anohter class with a lots of 
spldoublylinkedlists inside it. however, complex algorithm may be used...




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


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

Bug #63706 [Ver]: Cannot build PHP-5.5 with --enable-dtrace on Fedora 17

[dsp]

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

 ID: 63706
 Updated by: d...@php.net
 Reported by:sebast...@php.net
 Summary:Cannot build PHP-5.5 with --enable-dtrace on Fedora
 17
 Status: Verified
 Type:   Bug
 Package:*General Issues
 Operating System:   Fedora 17
 PHP Version:5.5Git-2012-12-06 (Git)
 Assigned To:    dsp
 Block user comment: N
 Private report: N

 New Comment:

go ahead and merge it then


Previous Comments:

[2012-12-15 08:12:33] sebast...@php.net

The patch solves the issue for me: I can build PHP-5.5 with --enable-dtrace.


[2012-12-11 07:12:10] r...@php.net

The following patch has been added/updated:

Patch Name: dtrace-cflags.patch
Revision:   1355209930
URL:
https://bugs.php.net/patch-display.php?bug=63706&patch=dtrace-cflags.patch&revision=1355209930


[2012-12-10 11:53:00] d...@php.net

This might be one of the issues, but my investigations said that usually the 
problem is that a main/main.o build is triggered by a prequisite of 
zend_dtrace.d.o that shouldnt be there.


[2012-12-10 11:49:33] r...@php.net

The issue seems to come from CFLAGS beeing exported, so used in the dtrace/gcc 
sub-process.

>From Makefile
CFLAGS = $(CFLAGS_CLEAN) -prefer-non-pic -static
CFLAGS_CLEAN = -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-fno-strict-aliasing -Wno-pointer-sign -fvisibility=hidden

Obviously -prefer-non-pic is not a gcc option, but a libtool one.

The attached patch use CFLAGS_CLEAN instead of CFLAGS for dtrace build.

It solves the dtrace build issue on fedora (and rpm) build.

If you think it's ok, I will apply it.


[2012-12-10 11:46:00] r...@php.net

The following patch has been added/updated:

Patch Name: dtrace-cflags.patch
Revision:   1355139960
URL:
https://bugs.php.net/patch-display.php?bug=63706&patch=dtrace-cflags.patch&revision=1355139960




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


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

Bug #62692 [Asn->Ver]: PHP fails to build with dtrace

[dsp]

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

 ID: 62692
 Updated by: d...@php.net
 Reported by:eugene at zhegan dot in
 Summary:PHP fails to build with dtrace
-Status: Assigned
+Status: Verified
 Type:   Bug
 Package:*General Issues
 Operating System:   Solaris 10 x86
 PHP Version:5.4.5
 Assigned To:    dsp
 Block user comment: N
 Private report: N



Previous Comments:

[2012-12-06 21:41:30] d...@php.net

Did you build any module as shared?


[2012-12-06 21:41:17] d...@php.net

This bug is about the dtrace probes in core not the PECL package.


[2012-09-14 15:46:48] eugene at zhegan dot in

Okay. Here are a bit more detailed instruction about how to actually and 
successfully build php with dtrace on Solaris. On Solaris Solaris, not on a 
dead body of Opensolaris or on shiny and rare Openindiana.

- Run configure with --enable-dtrace.

- You will probably need to use bundled gd, not system or installed from 
source, so use --with-gd, whithout a directory.

- It should work fine (actually, there are plenty of ways for it to fail 
depending on the various options, but let's assume you know how to build php on 
Solaris from sources and you're trying to build it with dtrace for now).

- Now you need to patch the Makefile the configure just created for you. Why ? 
Because Solaris sed doesn't have an -i switch. You can patch the Makefile as 
described here: https://bugs.php.net/bug.php?id=62691 or you can just install 
the GNU sed and make it appear in the PATH before the system sed.

- Now you can actually start building php, but read first this: 
https://bugs.php.net/bug.php?id=61268 . I'll make it easier: due to the fact 
that building will crash (see below) twice (see below :) ) you will need to 
prevent the zend_dtrace.d probe file from clobbering, due to the nature of 
gmake and some issues in the Makefile. :) This is done by using the '-r' 
switch, which prevents the make builtin rules from firing.

- Use gmake, it will make your life even more easier.

- Thus, you can run 'gmake -r' now and wait for it to crash.

- It will crash somewhere around making pfp-fpm (if you ordered this sapi) and 
the crash lines won't be similar the initial error in this report. The crash 
lines from the start of this report are caused by some clobbering and not using 
'gmake -r'. You should see a crash like this:

Undefined   first referenced
 symbol in file
__dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o
__dtrace_php___exception__thrownZend/.libs/zend_exceptions.o
__dtrace_php___errorZend/.libs/zend.o
__dtrace_php___function__entry  Zend/.libs/zend_dtrace.o
__dtrace_php___function__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__shutdownmain/.libs/main.o
__dtrace_php___exception__caughtZend/.libs/zend_execute.o
__dtrace_php___execute__return  Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
__dtrace_php___execute__entry   Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
$dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1

- lets discuss what is it and how to fix it. Somewhere over 9000 lines above 
the building process made this: 

dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d 
main/main.o Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o 
Zend/zend_dtrace.o Zend/zend.o

What is this ? This is the creation of the ELF binary with dtrace probes AND 
updating of the source object files. This is important. But these source object 
files at this point are already copied in the .libs directory, which linker is 
using at the final stage and where it does crash. They should be updated after 
running dtrace -G but they are not. In order to fix the building you should do 
it by hand:

- copy the files:

Zend/zend_API.o
Zend/zend_execute.o
Zend/zend_exceptions.o
Zend/zend_dtrace.o
Zend/zend.o

to the Zend/.libs

- copy the file

ma

Bug #62692 [Opn]: PHP fails to build with dtrace

[dsp]

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

 ID: 62692
 Updated by: d...@php.net
 Reported by:eugene at zhegan dot in
 Summary:PHP fails to build with dtrace
 Status: Open
 Type:   Bug
-Package:DTrace
+Package:*General Issues
 Operating System:   Solaris 10 x86
 PHP Version:5.4.5
-Assigned To:
+Assigned To:    dsp
 Block user comment: N
 Private report: N

 New Comment:

This bug is about the dtrace probes in core not the PECL package.


Previous Comments:

[2012-09-14 15:46:48] eugene at zhegan dot in

Okay. Here are a bit more detailed instruction about how to actually and 
successfully build php with dtrace on Solaris. On Solaris Solaris, not on a 
dead body of Opensolaris or on shiny and rare Openindiana.

- Run configure with --enable-dtrace.

- You will probably need to use bundled gd, not system or installed from 
source, so use --with-gd, whithout a directory.

- It should work fine (actually, there are plenty of ways for it to fail 
depending on the various options, but let's assume you know how to build php on 
Solaris from sources and you're trying to build it with dtrace for now).

- Now you need to patch the Makefile the configure just created for you. Why ? 
Because Solaris sed doesn't have an -i switch. You can patch the Makefile as 
described here: https://bugs.php.net/bug.php?id=62691 or you can just install 
the GNU sed and make it appear in the PATH before the system sed.

- Now you can actually start building php, but read first this: 
https://bugs.php.net/bug.php?id=61268 . I'll make it easier: due to the fact 
that building will crash (see below) twice (see below :) ) you will need to 
prevent the zend_dtrace.d probe file from clobbering, due to the nature of 
gmake and some issues in the Makefile. :) This is done by using the '-r' 
switch, which prevents the make builtin rules from firing.

- Use gmake, it will make your life even more easier.

- Thus, you can run 'gmake -r' now and wait for it to crash.

- It will crash somewhere around making pfp-fpm (if you ordered this sapi) and 
the crash lines won't be similar the initial error in this report. The crash 
lines from the start of this report are caused by some clobbering and not using 
'gmake -r'. You should see a crash like this:

Undefined   first referenced
 symbol in file
__dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o
__dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o
__dtrace_php___exception__thrownZend/.libs/zend_exceptions.o
__dtrace_php___errorZend/.libs/zend.o
__dtrace_php___function__entry  Zend/.libs/zend_dtrace.o
__dtrace_php___function__return Zend/.libs/zend_dtrace.o
__dtrace_php___request__shutdownmain/.libs/main.o
__dtrace_php___exception__caughtZend/.libs/zend_execute.o
__dtrace_php___execute__return  Zend/.libs/zend_dtrace.o
__dtrace_php___request__startup main/.libs/main.o
__dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o
__dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o
__dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o
__dtrace_php___execute__entry   Zend/.libs/zend_dtrace.o
__dtraceenabled_php___error Zend/.libs/zend.o
__dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o
$dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o
__dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1

- lets discuss what is it and how to fix it. Somewhere over 9000 lines above 
the building process made this: 

dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d 
main/main.o Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o 
Zend/zend_dtrace.o Zend/zend.o

What is this ? This is the creation of the ELF binary with dtrace probes AND 
updating of the source object files. This is important. But these source object 
files at this point are already copied in the .libs directory, which linker is 
using at the final stage and where it does crash. They should be updated after 
running dtrace -G but they are not. In order to fix the building you should do 
it by hand:

- copy the files:

Zend/zend_API.o
Zend/zend_execute.o
Zend/zend_exceptions.o
Zend/zend_dtrace.o
Zend/zend.o

to the Zend/.libs

- copy the file

main/main.o

to the main/.libs. They should differ by the way fromthe targets you have in 
.libs.

- issue a 'gmake -r' in the top php source directory so the building will 
continue. Important: issuing just 'gm

Bug #63704 [Opn]: Can't 'make' a second time with --enable-dtrace

[dsp]

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

 ID: 63704
 Updated by: d...@php.net
 Reported by:s...@php.net
 Summary:Can't 'make' a second time with --enable-dtrace
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Oracle Linux 6.3
 PHP Version:5.5 Git
-Assigned To:
+Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Changed it to "General issue" as this is a bug of the DTRaces probes in core 
not 
the DTrace package.


Previous Comments:

[2012-12-06 03:41:19] s...@php.net

After getting the error, the workaround is to do:
  git checkout Zend/zend_dtrace.d
and then repeat the 'make'.


[2012-12-06 03:20:13] s...@php.net

Description:

For any build with --enable-dtrace, running 'make' a second time after a 
successful build gives a compile failure.

Test script:
---
./configure --disable-all --enable-dtrace
make
make

Expected result:

Both 'make' commands succeed.

Actual result:
--
The actual result is the second 'make' fails like:

$ make
cc   /home/cjones/php-src/Zend/zend_dtrace.d.o   -o /home/cjones/php-
src/Zend/zend_dtrace.d
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [/home/cjones/php-src/Zend/zend_dtrace.d] Error 1






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

Bug #63704 [Asn->Opn]: Can't 'make' a second time with --enable-dtrace

[dsp]

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

 ID: 63704
 Updated by: d...@php.net
 Reported by:s...@php.net
 Summary:Can't 'make' a second time with --enable-dtrace
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Oracle Linux 6.3
 PHP Version:5.5 Git
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

Changed it to "General issue" as this is a bug of the DTRaces probes in core 
not 
the DTrace package.


Previous Comments:

[2012-12-06 21:39:16] d...@php.net

Changed it to "General issue" as this is a bug of the DTRaces probes in core 
not 
the DTrace package.


[2012-12-06 03:41:19] s...@php.net

After getting the error, the workaround is to do:
  git checkout Zend/zend_dtrace.d
and then repeat the 'make'.


[2012-12-06 03:20:13] s...@php.net

Description:

For any build with --enable-dtrace, running 'make' a second time after a 
successful build gives a compile failure.

Test script:
---
./configure --disable-all --enable-dtrace
make
make

Expected result:

Both 'make' commands succeed.

Actual result:
--
The actual result is the second 'make' fails like:

$ make
cc   /home/cjones/php-src/Zend/zend_dtrace.d.o   -o /home/cjones/php-
src/Zend/zend_dtrace.d
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [/home/cjones/php-src/Zend/zend_dtrace.d] Error 1






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

Bug #63686 [Asn->Csd]: Build with --enable-dtrace fails

[dsp]

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

 ID: 63686
 Updated by: d...@php.net
 Reported by:d...@php.net
 Summary:Build with --enable-dtrace fails
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Solaris
 PHP Version:5.5Git-2012-12-04 (Git)
 Assigned To:dmitry
 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-12-04 14:34:28] d...@php.net

Description:

building with --enable-dtrace results in 

Zend/zend.c:686:20: error: ‘dtrace_execute_ex’ undeclared (first use in 
this 
function)

which was introduced in

commit 70f83f35d089d0cafae12ae231a38541f5c8e41c
Author: Dmitry Stogov 
Date:   Fri Nov 30 13:39:23 2012 +0400


Test script:
---
./buildconf
./configure --enable-dtrace
make

Expected result:

build complete

Actual result:
--
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function 
‘dtrace_get_executed_filename’:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function ‘dtrace_execute’:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing argument 1 
of ‘get_active_class_name’ from incompatible pointer type [enabled by 
default]
In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0,
 from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22:
/home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected ‘const 
char 
**’ but argument is of type ‘char **’
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment 
discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment 
discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend.c: In function ‘zend_startup’:
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error: ‘dtrace_execute_ex’ 
undeclared (first use in this function)
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared identifier 
is reported only once for each function it appears in
make: *** [Zend/zend.lo] Error 1
make: *** Waiting for unfinished jobs







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

Bug #63686 [Opn->Asn]: Build with --enable-dtrace fails

[dsp]

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

 ID: 63686
 Updated by: d...@php.net
 Reported by:d...@php.net
 Summary:Build with --enable-dtrace fails
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Solaris
 PHP Version:5.5Git-2012-12-04 (Git)
-Assigned To:
+Assigned To:dmitry
 Block user comment: N
 Private report: N



Previous Comments:

[2012-12-04 14:34:28] d...@php.net

Description:

building with --enable-dtrace results in 

Zend/zend.c:686:20: error: ‘dtrace_execute_ex’ undeclared (first use in 
this 
function)

which was introduced in

commit 70f83f35d089d0cafae12ae231a38541f5c8e41c
Author: Dmitry Stogov 
Date:   Fri Nov 30 13:39:23 2012 +0400


Test script:
---
./buildconf
./configure --enable-dtrace
make

Expected result:

build complete

Actual result:
--
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function 
‘dtrace_get_executed_filename’:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:30:3: warning: return discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:32:3: warning: return discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c: In function ‘dtrace_execute’:
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:3: warning: passing argument 1 
of ‘get_active_class_name’ from incompatible pointer type [enabled by 
default]
In file included from /home/dsp/dev/php/src/5.5/Zend/zend_API.h:30:0,
 from /home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:22:
/home/dsp/dev/php/src/5.5/Zend/zend_execute.h:348:53: note: expected ‘const 
char 
**’ but argument is of type ‘char **’
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:62:13: warning: assignment 
discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend_dtrace.c:63:12: warning: assignment 
discards 
‘const’ qualifier from pointer target type [enabled by default]
/home/dsp/dev/php/src/5.5/Zend/zend.c: In function ‘zend_startup’:
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: error: ‘dtrace_execute_ex’ 
undeclared (first use in this function)
/home/dsp/dev/php/src/5.5/Zend/zend.c:686:20: note: each undeclared identifier 
is reported only once for each function it appears in
make: *** [Zend/zend.lo] Error 1
make: *** Waiting for unfinished jobs







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

Bug #50400 [Fbk->NoF]: Compile fails generating phar.phar

[dsp]

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

 ID: 50400
 Updated by: d...@php.net
 Reported by:lepage at grm dot polymtl dot ca
 Summary:Compile fails generating phar.phar
-Status: Feedback
+Status: No Feedback
 Type:   Bug
 Package:PHAR related
 Operating System:   Solaris 10
 PHP Version:5.3.1
 Assigned To:    dsp
 Block user comment: N
 Private report: N

 New Comment:

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.




Previous Comments:

[2010-09-28 15:26:17] steve at computurn dot com

I have a fix for this issue (PHP5.3.3)

It's caused by ext/phar/build_precommand.php having a header of #!/usr/bin/php
I fixed it on my system by creating a /usr/bin/php symlink to a php executable, 
but I suspect the proper fix will be to change the #! to point to sapi/cli/php, 
if that's built when we get to this stage.


[2010-07-05 21:43:00] omars1234 at gmail dot com

Tried the new snapshot, no luck.  Using Solaris10, gcc 4.2.1.  Configured 
without any options.

Generating phar.php
*** Error code 139
The following command caused the error:
`  if test -x "/tmp/php5.3-201007051830/sapi/cli/php"; then  
/tmp/php5.3-201007051830/build/shtool echo -n -- 
"/tmp/php5.3-201007051830/sapi/cli/php -n";  if test "x" != "x"; then  
/tmp/php5.3-201007051830/build/shtool echo -n -- " -d 
extension_dir=/tmp/php5.3-201007051830/modules";  for i in bz2 zlib phar; do  
if test -f "/tmp/php5.3-201007051830/modules/$i.la"; then  . 
/tmp/php5.3-201007051830/modules/$i.la; /tmp/php5.3-201007051830/build/shtool 
echo -n -- " -d extension=$dlname";  fi;  done;  fi;  else  
/tmp/php5.3-201007051830/build/shtool echo -n -- 
"/tmp/php5.3-201007051830/sapi/cli/php";  fi;` -d 'open_basedir=' -d 
'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' 
/tmp/php5.3-201007051830/ext/phar/build_precommand.php > ext/phar/phar.php
make: Fatal error: Command failed for target `ext/phar/phar.php'

(my disable-phar version didn't work out either, resulting cli-binary core 
dumps :( )


[2010-07-02 11:33:17] johan...@php.net

Please try using this snapshot:

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

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


[2010-07-02 01:04:44] omars1234 at gmail dot com

As a work-around, pass "--disable-phar" to configure.  I don't do anything that 
explicitly needs phar archives (so far), so I did this to build PHP5.3.2 on 
Solaris10 after running into the same problem.


[2010-01-26 17:09:36] ekcheu at uncg dot edu

I've had this issue before.  It appears that this error occurs depending upon 
which version of gcc you are using.  After continuing to fail to compile on a 
version of gcc (4.2.1).. I used blastwave's gcc, and it was able to get past 
this issue.  Don't ask why it compiles find on some versions of gcc and not 
others.




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


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

Req #47871 [Asn]: PHPIniScanDir directive for apache allows scanning for extension ini files

[dsp]

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

 ID: 47871
 Updated by: d...@php.net
 Reported by:sriram dot natarajan at gmail dot com
 Summary:PHPIniScanDir directive for apache allows scanning
 for extension ini files
 Status: Assigned
 Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   unix and linux
 PHP Version:5.3.0RC1
 Assigned To:    dsp
 Block user comment: N
 Private report: N

 New Comment:

Sriram, sorry for totally having forgotten about that patch. I think we might 
be 
able to add it to 5.5.0 if someone pushes for it. I yet have to test if the 
patch 
works with 5.5.0


Previous Comments:

[2011-02-08 03:29:13] srina...@php.net

i believe, with my initial patch the idea was that introduce a directive like 
PhpIniScanDir within httpd.conf so that this can scan a directory.


[2011-02-02 23:34:15] tyra3l at gmail dot com

for the record: passing PHP_INI_SCAN_DIR through SetEnv from apache confid 
doesnt 
work: the environment variable will be there(at least by phpinfo()), but the 
"Scan 
this dir for additional .ini files" will be empty.
on the other hand, if you set/export an environment variable in the shell where 
you start the apache afterwards, that does work.
so for now, one can set this option "runtime", but it would be a nicer 
solution, 
if the apache SetEnv would work, or if the patch would be merged, so we would 
have 
an apache directive called PHP_INI_SCAN_DIR.

Tyrael


[2011-02-02 22:04:21] tyra3l at gmail dot com

poke

Tyrael


[2009-05-04 18:19:16] sriram dot natarajan at gmail dot com

how does this work ? will this need to be ported all the sapi's currently 
supported by PHP or can it be on a user request basis ? for, example - i can 
provide the patch for ISAPI ? will that help ? 

For NSAPI, lot of things are broke as is. for example, php ini dir itself does 
not work with recent version of sun web server. I plan to  file a separate bug 
for NSAPI and can provide a separate patch to address this issue for nsapi.  

I don't have lot of experience with thttpd or roxen. Does this patch need to be 
ported to those SAPI's as well ? are these SAPI's actively used by the 
community ?


[2009-05-04 15:12:54] paj...@php.net

David, what's the status about this one? Should it not be for all SAPI instead?




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


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

Bug #61268 [Asn->Fbk]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

[dsp]

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

 ID: 61268
 Updated by: d...@php.net
 Reported by:mike at harschsystems dot com
 Summary:--enable-dtrace leads make to clobber
 Zend/zend_dtrace.d
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   solaris
 PHP Version:5.4.0
 Assigned To:    dsp
 Block user comment: N
 Private report: N

 New Comment:

I see what the problem is but cannot reproduce it myself with 5.5.0alpha1. 
Please try the 5.5.0alpha snapshots from http://downloads.php.net/dsp and 
provide me with 'uname -a' and 'gmake --version'.

./configure && gmake works fine for me on

$ uname -a
SunOS foo 5.11 11.0 i86pc i386 i86pc Solaris

which is a Oracle Solaris 5.11.

$ gmake -- version
GNU Make 3.81


Previous Comments:

[2012-05-08 04:35:50] mike at harschsystems dot com

I've seen the same failing behavior on 5.4.1 as well.  It's worth noting that 
gmake exhibits this failure mode while regular (non-GNU) make works fine.  So, 
the 
2 workarounds are:

1.) run gmake with the '-r' option
or
2.) run non-GNU make instead of gmake


[2012-04-22 13:13:01] alasdairrr at gmail dot com

I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS.


[2012-03-03 20:19:39] mike at harschsystems dot com

Description:

5.4.0 bundle configured with only one option: --enable-dtrace

The configure script runs fine and the build finishes without error.  However, 
the next invocation of 
make (probably from trying to run 'make install') fails with the following 
error:


[jack@fjpe6maa ~/php-5.4.0]$ make install
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d
Undefined   first referenced
 symbol in file
main/usr/lib/crt1.o
php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute  /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_throw_exception_internal   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
$dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php-
5.4.0/Zend/zend_dtrace.d.o
zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
ld: fatal: symbol referencing errors. No output written to /home/jack/php-
5.4.0/Zend/zend_dtrace.d
collect2: ld returned 1 exit status
make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1

What's happening here is that make has determined that the file 
Zend/zend_dtrace.d is out of date and 
must be rebuilt.  It matches a built-in implicit rule that ends up running:
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d

This command fails with the error that you see, but it also clobbers 
zend_dtrace.d

Here's a bit more detail from 'make -d':
 
 Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer 
than target 
`/home/jack/php-5.4.0/Zend/zend_dtrace.d'.
Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'.
Invoking builtin recipe to update target `/home/jack/php-
5.4.0/Zend/zend_dtrace.d'.
gcc   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o   -o /home/jack/php-
5.4.0/Zend/zend_dtrace.d
Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the 
chain.
Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104
Undefined   first referenced
 symbol in file
main/usr/lib/crt1.o
php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_execute  /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
$dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php-
5.4.0/Zend/zend_dtrace.d.o
php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_throw_exception_internal   /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o
ld: fatal: symbol referencing errors. No output written to /home/jack/php-
5.4.0/Zend/zend_dtrace.d
collect2: ld retu

Bug #62593 [Ver->Csd]: Emulate prepares behave strangely with PARAM_BOOL

[dsp]

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

 ID: 62593
 Updated by: d...@php.net
 Reported by:mascione at sviluppo dot toscana dot it
 Summary:Emulate prepares behave strangely with PARAM_BOOL
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 10.04
 PHP Version:5.3.14
 Assigned To:willfitch
 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-10-17 07:50:12] franck dot borel at ub dot uni-freiburg dot de

I am running the test script on SLES11 SP2 with PHP 5.2.14 and I have the same 
error described here!


[2012-10-10 21:30:20] willfi...@php.net

This was accepted and is awaiting merge.


[2012-09-20 16:36:16] willfi...@php.net

Pull request for this fix:

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


[2012-09-18 10:04:19] v dot picture at free dot fr

Same problem with the stock version on Ubuntu 12.04: PHP 5.3.10-1ubuntu3.4 
(built: Sep 12 2012)
I hope this problem will be solved soon.


[2012-09-17 16:17:24] willfi...@php.net

I have confirmed this.  The issue with disabling emulation prepares for this 
purpose is that it sends the query through PQprepare, then PQexec.  If you're 
using middleware such as pgbouncer, this won't work.




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


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

Bug #61464 [Opn->Spm]: Test bug, please ignore

[dsp]

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

 ID: 61464
 Updated by: d...@php.net
 Reported by:f...@php.net
 Summary:Test bug, please ignore
-Status: Open
+Status: Spam
 Type:   Bug
 Package:*General Issues
 Operating System:   any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2012-03-21 14:35:44] f...@php.net

Automatic comment on behalf of fa
Revision: 
http://git.php.net/?p=playground.git;a=commit;h=237a59bd1525d8c8cda6eda61019fad885c29fd9
Log: Fixed bug #61464


[2012-03-21 14:26:25] f...@php.net

Automatic comment on behalf of fa
Revision: 
http://git.php.net/?p=git/repositories/playground.git;a=commit;h=7b05ac521433dfe66f631ddd61554c6830b62e9e
Log: Fixed bug #61464


[2012-03-21 13:51:22] f...@php.net@php.net

Automatic comment on behalf of f...@php.net
Revision: 
http://git.php.net/?p=playground.git.git;a=commit;h=4341dcfbeec4ceeef0665906f92a54b46c50ea9d
Log: Fixed bug #61464


[2012-03-21 13:47:32] florian.anderia...@mayflower.de@php.net

Automatic comment on behalf of florian.anderia...@mayflower.de
Revision: 
http://git.php.net/?p=playground.git.git;a=commit;h=462ad56763fc490c74317640641b15273404f7a6
Log: Fixed bug #61464


[2012-03-21 12:46:17] f...@php.net

Description:

Test bug, please ignore, and don't close it either.

Test script:
---
Test bug, please ignore, and don't close it either.

Expected result:

Test bug, please ignore, and don't close it either.

Actual result:
--
Test bug, please ignore, and don't close it either.






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

Bug #55371 [Asn->Csd]: get_magic_quotes_gpc() throws deprecation warning

[dsp]

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

 ID: 55371
 Updated by: d...@php.net
 Reported by:thbley at gmail dot com
 Summary:get_magic_quotes_gpc() throws deprecation warning
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
 Assigned To:    dsp
 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.

Thanks david, patch applied.


Previous Comments:

[2011-11-15 13:22:42] d...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=319249
Log: Fixed bug #55371 (get_magic_quotes_gpc() throws deprecation warning.)

Patch by David Zuelke <david dot zuelke at bitextender dot com>


[2011-11-15 13:09:43] paj...@php.net

Let me clarify this pointer. Getter should not raise any warning. Setters do.


[2011-11-15 13:01:45] david dot zuelke at bitextender dot com

A warning definitely is a bad idea, it makes it impossible to write portable 
code 
to detect magic quotes without version check stunts. It's fine if the two 
functions simply return false forever, there's not even a need to remove them 
as 
they don't do any harm whatsoever.


[2011-11-15 12:58:20] paj...@php.net

Hi David,

please do it, I do not have the time to do it before RC2.

Cheers,


[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.




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


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

Bug #55371 [Opn->Asn]: Function get_magic_quotes_gpc() is deprecated

[dsp]

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

 ID: 55371
 Updated by: d...@php.net
 Reported by:thbley at gmail dot com
 Summary:Function get_magic_quotes_gpc() is deprecated
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Win7 6.1.7600
 PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:pajoye
 Block user comment: N
 Private report: N



Previous Comments:

[2011-11-14 11:14:00] bj...@php.net

Throwing any kind of warnings for the getters is a cruel punishment targetting 
the people who were actually dealing with the problem we gave them in the first 
place.


[2011-11-12 21:57:29] tyr...@php.net

Just my 2 cents: 
I think that raising an E_DEPRECATED now is better, if we want to remove the 
get 
methods with the major/minor version after 5.4.


[2011-11-12 12:12:01] david dot zuelke at bitextender dot com

According to several mailing list threads I've searched, it should not give a 
deprecation warning. So it's not a documentation problem but a bug. The 
attached 
patch fixes the problem (uses PHP_FE instead of PHP_DEP_FE for 
get_magic_quotes_gpc() and get_magic_quotes_runtime()) and adds and updates 
tests 
accordingly.


[2011-11-07 02:54:54] 44318209 at qq dot com

I have the same problem


[2011-10-27 11:27:19] a at b dot c dot de

NEWS_5_4_0_beta1.txt mentions that get_magic_quotes_{gpc|runtime}() always 
return false, but not that they're deprecated.




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


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

Bug #60218 [Ana->Csd]: instantiating unknown class leads to memory leak in cli

[dsp]

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

 ID: 60218
 Updated by: d...@php.net
 Reported by:yohgaki at ohgaki dot net
 Summary:instantiating unknown class leads to memory leak in
 cli
-Status: Analyzed
+Status: Closed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
-Assigned To:
+Assigned To:    dsp
 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:

[2011-11-12 16:49:38] d...@php.net

updated the title


[2011-11-12 16:40:48] d...@php.net

The following patch has been added/updated:

Patch Name: ensure-efree-of-oparray
Revision:   1321116048
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=ensure-efree-of-oparray&revision=1321116048


[2011-11-12 16:39:04] d...@php.net

The following patch has been added/updated:

Patch Name: 60218-try-catch-efree-op-array
Revision:   1321115944
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=60218-try-catch-efree-op-array&revision=1321115944


[2011-11-12 16:38:41] d...@php.net

I added a patch that fixes it for me


[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.




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


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

Bug #60218 [Ana]: instantiating new class leads to memory leak in cli

[dsp]

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

 ID: 60218
 Updated by: d...@php.net
 Reported by:yohgaki at ohgaki dot net
-Summary:dir() is missing
+Summary:instantiating new class leads to memory leak in cli
 Status: Analyzed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

updated the title


Previous Comments:

[2011-11-12 16:40:48] d...@php.net

The following patch has been added/updated:

Patch Name: ensure-efree-of-oparray
Revision:   1321116048
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=ensure-efree-of-oparray&revision=1321116048


[2011-11-12 16:39:04] d...@php.net

The following patch has been added/updated:

Patch Name: 60218-try-catch-efree-op-array
Revision:   1321115944
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=60218-try-catch-efree-op-array&revision=1321115944


[2011-11-12 16:38:41] d...@php.net

I added a patch that fixes it for me


[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.


[2011-11-04 18:08:58] s...@php.net

1. The documentation examples don't use 'new'.  This works:
  php -r '$o = dir(".");'
2. SPL might have better alternatives, e.g.:
  http://www.php.net/manual/en/class.recursivedirectoryiterator.php
3. I'll leave the bug open to track the memleak




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


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

Bug #60218 [Opn->Ana]: dir() is missing

[dsp]

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

 ID: 60218
 Updated by: d...@php.net
 Reported by:yohgaki at ohgaki dot net
 Summary:dir() is missing
-Status: Open
+Status: Analyzed
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
 Block user comment: N
 Private report: N



Previous Comments:

[2011-11-12 16:40:48] d...@php.net

The following patch has been added/updated:

Patch Name: ensure-efree-of-oparray
Revision:   1321116048
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=ensure-efree-of-oparray&revision=1321116048


[2011-11-12 16:39:04] d...@php.net

The following patch has been added/updated:

Patch Name: 60218-try-catch-efree-op-array
Revision:   1321115944
URL:
https://bugs.php.net/patch-display.php?bug=60218&patch=60218-try-catch-efree-op-array&revision=1321115944


[2011-11-12 16:38:41] d...@php.net

I added a patch that fixes it for me


[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.


[2011-11-04 18:08:58] s...@php.net

1. The documentation examples don't use 'new'.  This works:
  php -r '$o = dir(".");'
2. SPL might have better alternatives, e.g.:
  http://www.php.net/manual/en/class.recursivedirectoryiterator.php
3. I'll leave the bug open to track the memleak




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


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

Bug #60218 [Opn]: dir() is missing

[dsp]

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

 ID: 60218
 Updated by: d...@php.net
 Reported by:yohgaki at ohgaki dot net
 Summary:dir() is missing
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux x86_64
 PHP Version:5.4SVN-2011-11-04 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I added a patch that fixes it for me


Previous Comments:

[2011-11-05 00:32:16] yohgaki at ohgaki dot net

> 1. The documentation examples don't use 'new'.  This works:
> php -r '$o = dir(".");'

It should always raise error for it, I suppose. 
Strange thing is 'It works' sometimes.

If leak and other problem(works for sometimes) are specific to dir(), I think 
dropping dir() is an option.


[2011-11-04 18:08:58] s...@php.net

1. The documentation examples don't use 'new'.  This works:
  php -r '$o = dir(".");'
2. SPL might have better alternatives, e.g.:
  http://www.php.net/manual/en/class.recursivedirectoryiterator.php
3. I'll leave the bug open to track the memleak


[2011-11-04 14:10:53] yohgaki at ohgaki dot net

dir is ancient class in PHP, so it may be the first one. It may be related. 
Just 
my guess.


[2011-11-04 14:06:43] yohgaki at ohgaki dot net

s/I support dir()/I suppose dir()/


[2011-11-04 14:02:52] yohgaki at ohgaki dot net

Description:

I support dir() support is not dropped.
http://jp.php.net/manual/en/class.dir.php

At first, I noticed this issue on Scientific Linux 6's PHP and not with my 
Linux 
box. I though they have patched something for it, but I found it can happen 
with 
my Linux box, too.

This happens in PHP 5.3.3, PHP 5.3.8 and php-src-5.4 at least.
This may not be 100% reproducible, but I think chances are high in SL6. PHP may 
be destroying class entry.

I'm not sure following valgrind result may help or not, but "echo 1" don't 
report any leak.

$ USE_ZEND_ALLOC=0 valgrind --leak-check=full ./php -r '$o = new Dir(".");'
==24918== Memcheck, a memory error detector
==24918== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==24918== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==24918== Command: ./php -r $o\ =\ new\ Dir(".");
==24918== 
PHP Fatal error:  Class 'Dir' not found in Command line code on line 1

Fatal error: Class 'Dir' not found in Command line code on line 1
==24918== 
==24918== HEAP SUMMARY:
==24918== in use at exit: 724 bytes in 6 blocks
==24918==   total heap usage: 15,100 allocs, 15,094 frees, 3,101,573 bytes 
allocated
==24918== 
==24918== 724 (240 direct, 484 indirect) bytes in 1 blocks are definitely lost 
in loss record 6 of 6
==24918==at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==24918==by 0x7A6845: _emalloc (zend_alloc.c:2423)
==24918==by 0x782E75: compile_string (zend_language_scanner.l:717)
==24918==by 0x7CDC99: zend_eval_stringl (zend_execute_API.c:1181)
==24918==by 0x7CE00D: zend_eval_stringl_ex (zend_execute_API.c:1240)
==24918==by 0x7CE097: zend_eval_string_ex (zend_execute_API.c:1251)
==24918==by 0x93C6E1: do_cli (php_cli.c:1023)
==24918==by 0x93D625: main (php_cli.c:1356)
==24918== 
==24918== LEAK SUMMARY:
==24918==definitely lost: 240 bytes in 1 blocks
==24918==indirectly lost: 484 bytes in 5 blocks
==24918==  possibly lost: 0 bytes in 0 blocks
==24918==still reachable: 0 bytes in 0 blocks
==24918== suppressed: 0 bytes in 0 blocks
==24918== 
==24918== For counts of detected and suppressed errors, rerun with: -v
==24918== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)


**

$ USE_ZEND_ALLOC=0 valgrind --leak-check=full ./php -r "echo 1;"
==28266== Memcheck, a memory error detector
==28266== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28266== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28266== Command: ./php -r echo\ 1;
==28266== 
1==28266== 
==28266== HEAP SUMMARY:
==28266== in use at exit: 0 bytes in 0 blocks
==28266==   total heap usage: 15,078 allocs, 15,078 frees, 3,099,330 bytes 
allocated
==28266== 
==28266== All heap blocks were freed -- no leaks are possible
==28266== 
==28266== For counts of detected and suppressed errors, rerun with: -v
==28266== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)


Test script:
---
php -r '$o = new Dir(".");'


Expected result:

PHP should not complain

Actual result:
--
Fatal error: Class 'Dir' not found in Command 

Bug #55269 [Asn->Csd]: --enable-dtrace fail on FreeBSD

[dsp]

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

 ID: 55269
 Updated by: d...@php.net
 Reported by:samm at os2 dot kiev dot ua
 Summary:--enable-dtrace fail on FreeBSD
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   FreeBSD 8-STABLE
 PHP Version:5.4SVN-2011-07-22 (SVN)
 Assigned To:    dsp
 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:

[2011-07-26 23:49:38] d...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=313752
Log: Fix #55269 (--enable-dtrace fail on FreeBSD)


[2011-07-22 15:19:01] samm at os2 dot kiev dot ua

Description:

Dtrace/userland is supported in the current FreeBSD version. I found that 
autoconf expecting Solaris only and producing broken makefiles on FreeBSD. Also 
libelf is required on FreeBSD to link with dtrace for userland applications.

Test script:
---
./buildconf; configure --enable-dtrace && make


Expected result:

php with dtrace

Actual result:
--
a lot of unresolved functions on the link stage.






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

Bug #55211 [Opn->Ver]: ArrayObject::getArrayObject ()

[dsp]

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

 ID: 55211
 Updated by: d...@php.net
 Reported by:suman dot madavapeddi at gmail dot com
 Summary:ArrayObject::getArrayObject ()
-Status: Open
+Status: Verified
 Type:   Bug
 Package:SPL related
 Operating System:   windows 7 Professional
 PHP Version:5.3.6
 Block user comment: N
 Private report: N



Previous Comments:

[2011-07-14 20:46:31] suman dot madavapeddi at gmail dot com

Description:

---
>From manual page: http://www.php.net/arrayobject.getarraycopy%23Description
---


when it is referred to an object it should return only public properties of an 
object .But, Instead it is returning all the Properties of an Object

Test script:
---
class MyClass{
public $pbvar = "public Variable";
private $prvar = "Private Variable";
protected $pdvar = "Protected Variable";
}


$ar  = new ArrayObject( new MyClass());
$arc = $ar->getArrayCopy();
print_r($arc);


Expected result:

Array
(
[pbvar] => public Variable
   
)

Actual result:
--
Array
(
[pbvar] => public Variable
[MyClass5prvar] => Private Variable
[*pdvar] => Protected Variable
)






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

Bug #55223 [Opn->Bgs]: isset triggers fatal error when accessing object as array

[dsp]

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

 ID: 55223
 Updated by: d...@php.net
 Reported by:Sjon at hortensius dot net
 Summary:isset triggers fatal error when accessing object as
 array
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Arrays related
 Operating System:   Archlinux
 PHP Version:5.3.6
 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




Previous Comments:

[2011-07-20 16:07:14] binarycleric at gmail dot com

It's not isset that's triggering this error.  The reason is that "$x['a']" is 
not 
valid when $x is an object.

Just for (cheap and lazy) regression purposes I tried this on PHP 5.2.17 and 
the 
same thing occurred so I don't think #53971 had anything to do with it.


[2011-07-18 04:09:18] Sjon at hortensius dot net

Description:

This worked for quite a long time, but stopped working recently, I suspect due 
to 
#53971 being fixed. I think isset should never trigger any error

Test script:
---
$x = new stdClass;
$x->a = 'b';
var_dump(isset($x['a']));

Expected result:

false

Actual result:
--
PHP Fatal error:  Cannot use object of type stdClass as array in php shell code 
on line 1






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

Bug #55254 [Opn->Bgs]: strpos() performs more poorly when offset specified

[dsp]

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

 ID: 55254
 Updated by: d...@php.net
 Reported by:webmaster at thedigitalorchard dot ca
 Summary:strpos() performs more poorly when offset specified
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Performance problem
 Operating System:   OS X 10.6.8
 PHP Version:5.3.6
 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

it's related to parameter passing.


Previous Comments:

[2011-07-20 19:42:49] webmaster at thedigitalorchard dot ca

This issue that I've observed may in fact not be related to strpos() at all, 
but 
merely the fact that there's one more parameter to parse. Passing in zero "0" 
as 
the third parameter gives the same result as any other offset. Removing the 
parameter restores the performance.

In a way, this makes sense, but maybe this highlights an area where PHP/Zend 
can 
be improved further -- parameter parsing.

Feel free to close this bug report if my assessment of this performance issue 
is 
accurate.


[2011-07-20 18:37:52] webmaster at thedigitalorchard dot ca

Changed summary title to be more clear (replaced "index" with "offset")


[2011-07-20 18:13:46] webmaster at thedigitalorchard dot ca

Description:

When strpos() is given an index position to start searching, it actually 
performs 
more poorly than when the parameter is left off (thus defaulting to "0"). One 
would expect that giving it a starting index would improve performance since it 
could skip checking so many characters.

I've been able to reproduce this issue consistently with the attached script.

Two loops, each run 1 million times. The first loop specifies a start index of 
2, 
whereas the second one doesn't specify one. You would expect the first loop to 
run 
faster. Try reversing this (giving the second loop a start index) and you will 
see 
the execution time results flip, as well.

My framework makes heavy use of strpos() and I discovered this issue when I 
attempted to optimize strpos() by skipping the first few characters of the 
string 
to be checked. No go.

Test script:
---
Seconds: ".(microtime(TRUE) - $start).'';

$start = microtime(TRUE);

for ($i = 0; $i < 100; $i++) {
strpos($k, '{');
}

echo "Seconds: ".(microtime(TRUE) - $start).'';

Expected result:

Specifying a start index would result in better performance since it has less 
to 
check.

Actual result:
--
Specifying a start index actually has a negative impact on the performance of 
the 
script, possibly due to logic where it must check if the index is positive or 
negative.






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

Req #55212 [Opn->Csd]: Detect whether IPv6 is enabled with STREAM_PF_INET6

[dsp]

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

 ID: 55212
 Updated by: d...@php.net
 Reported by:ivan dot enderlin at hoa-project dot net
 Summary:Detect whether IPv6 is enabled with STREAM_PF_INET6
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Network related
 PHP Version:5.4SVN-2011-07-15 (SVN)
-Assigned To:
+Assigned To:    dsp
 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.

I think we should not define STREAM_PF_INET6 in case we have IPv6 disabled. 
Patch committed (sorry, I forgot to include your credits :/)


Previous Comments:

[2011-07-15 11:25:20] d...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=313267
Log: Fix #55212. Only declare STREAM_PF_INET6 if PHP is compiled with IPv6 
support


[2011-07-15 04:40:10] ivan dot enderlin at hoa-project dot net

Description:

If PHP has been compiled with the --disable-ipv6 option, the constant 
STREAM_PF_INET6 should not exist. It could be useful to detect whether IPv6 has 
been enabled. To ensure BC, it would be better to set STREAM_PF_INET6 to -1 (or 
0, false…).

We could already detect if IPv6 has been disabled with the AF_INET6 constant, 
declared in ext/sockets/sockets.c with #if HAVE_IPV6, but this solution is 
worthless if PHP has been compiled with the --disable-socket option. We could 
use IPv6 with stream_* functions, not only with socket_* functions.

Test script:
---
$ php -r "var_dump(defined('STREAM_PF_INET6'), STREAM_PF_INET6);"
$ php -i | grep "IPv6"

Expected result:

bool(true)
int(-1)
IPv6 Support => disabled

Actual result:
--
bool(true)
int(30)
IPv6 Support => disabled






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

Req #54683 [Opn->Bgs]: $var = NULL; isset($var) return FALSE

[dsp]

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

 ID: 54683
 Updated by: d...@php.net
 Reported by:langpavel at phpskelet dot org
 Summary:$var = NULL; isset($var) return FALSE
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   all
 PHP Version:Irrelevant
 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




Previous Comments:

[2011-05-07 02:04:03] langpavel at phpskelet dot org

Description:

---
>From manual page: http://www.php.net/function.isset#Description
---

if valid variable $var with NULL value passed to isset(), result is FALSE.

There should be language reserved word/language construct that behaves exactly 
like isset() except for NULL value.

behavior of isset should be changed in future major release, optionally 
configurable by ini setting.

If I create patch, do you include it? 
Note that if I'll go implement this, compatible behavior will be preserved.

Test script:
---
if(isset($var))
die('ERROR');
else
echo "OK\n";

$var = null;
if(!isset($var)) 
die('NOT GOOD. THIS IS UNCLEAR AND STRANGE');
else
echo "THIS IS BETTER\n";

unset($var);
if(isset($var)) 
die('ERROR');
else
echo "OK\n";


Expected result:

OK
THIS IS BETTER
OK


Actual result:
--
OK
NOT GOOD. THIS IS UNCLEAR AND STRANGE






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

Bug #54925 [Opn]: build php on solaris for 64 bits

[dsp]

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

 ID: 54925
 Updated by: d...@php.net
 Reported by:michel dot henaut at everyware dot ch
 Summary:build php on solaris for 64 bits
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   solaris
 PHP Version:5.2.17
-Assigned To:
+Assigned To:srinatar
 Block user comment: N
 Private report: N

 New Comment:

assigning this to people working at oracle.


Previous Comments:

[2011-05-27 07:39:20] eugene at zhegan dot in

Same here.
PHP 5.3.6.

# cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03

Same workaround does help (thanks, Michael, by the way).


[2011-05-25 14:31:09] michel dot henaut at everyware dot ch

Description:

Build php on solaris with Sun compiler:

The default build for 64 bits, i.e. CFLAGS='-m64' produces strange results.
Rebuilding all with CFLAGS='-m64 -O -xs -xstrconst -zlazyload' seems to work.

To reproduce it:

$obj[0]['data'][0]['Usr'] = 0.009035;
echo json_encode($obj);

with just CFLAGS='-m64'
[{"data":[{"Usr":INF}]}]

with CFLAGS='-m64 -O -xs -xstrconst -zlazyload'
[{"data":[{"Usr":0.009035}]}]
which is correct.

may be a problem in main/snprintf.c and in main/spprintf.c

regards 




Test script:
---
$obj[0]['data'][0]['Usr'] = 0.009035;
echo json_encode($obj);


Expected result:

[{"data":[{"Usr":0.009035}]}]

Actual result:
--
[{"data":[{"Usr":INF}]}]






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

Bug #55072 [Opn->Csd]: In-built web server needs to check -t option is a directory

[dsp]

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

 ID: 55072
 Updated by: d...@php.net
 Reported by:s...@php.net
 Summary:In-built web server needs to check -t option is a
 directory
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 Operating System:   Linux
 PHP Version:5.4SVN-2011-06-29 (SVN)
-Assigned To:
+Assigned To:    dsp
 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.

fixed in r312643
http://svn.php.net/viewvc?view=revision&revision=312643


Previous Comments:

[2011-06-29 17:15:42] s...@php.net

Description:

The PHP 5.4 in-built webserver needs validate that the -t argument is a 
directory.






Test script:
---
$ php54 -n -S localhost:8000 -t routing.php

Expected result:

$ php54 -n -S localhost:8000 -t routing.php 
"routing.php is not a directory."

(or a better phrased error message)

Actual result:
--
$ php54 -n -S localhost:8000 -t routing.php 
Server is listening on localhost:8000 in routing.php ... Press CTRL-C to quit.






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

Bug #54419 [Opn->Bgs]: is_dir() called on file with trailing slash to throw warning if open_basedir

[dsp]

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

 ID: 54419
 Updated by: d...@php.net
 Reported by:david dot macek dot 0 at gmail dot com
 Summary:is_dir() called on file with trailing slash to throw
 warning if open_basedir
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Safe Mode/open_basedir
 Operating System:   Windows 7, Debian
 PHP Version:5.3.6
 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 expected behaviour. A non path that doesn't exists (the one with the 
slash) is considered outside of the basedir.


Previous Comments:

[2011-03-29 21:08:10] david dot macek dot 0 at gmail dot com

Description:

is_dir throws an error if:

- open_basedir is in effect

- called upon a file

- the path is terminated with a slash



CLI Tested on Windows:

php -d open_basedir=/ -r "var_dump(is_dir('C:/Windows/write.exe'));"

#bool(false)

php -d open_basedir=/ -r "var_dump(is_dir('C:/Windows/write.exe/'));"

#warning



CLI Not tested on Linux, should be like this:

php -d open_basedir=/ -r "var_dump(is_dir('/etc/fstab'));"



Apache2 module tested on Debian, see test script.

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

Bug #54462 [Opn->Fbk]: 'echo $e->getTrace()' hangs

[dsp]

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

 ID: 54462
 Updated by: d...@php.net
 Reported by:softwarevamp at gmail dot com
 Summary:'echo $e->getTrace()' hangs
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Output Control
 Operating System:   Window Xp Japanese
 PHP Version:5.2.17
 Block user comment: N
 Private report: N

 New Comment:

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.

cannot reproduce it. please provide a stack trace where it's hanging.


Previous Comments:

[2011-04-04 04:06:43] softwarevamp at gmail dot com

Description:

try to print out exception stacktrace, php hangs.

Test script:
---
try {

   throw new ErrorException("test");

} catch(Exception $e) {

echo $e; //hangs here

}

i am using WINDOWS XP JAPANESE

Expected result:

print out the stack trace

Actual result:
--
hangs






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

Bug #54544 [Opn->Fbk]: gmake test Fails See Below:

[dsp]

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

 ID: 54544
 Updated by: d...@php.net
 Reported by:tdineen at ix dot netcom dot com
 Summary:gmake test Fails See Below:
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   Solaris 10 Intel
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Does the file exist?


Previous Comments:

[2011-04-16 05:10:55] tdineen at ix dot netcom dot com

Description:

Please do not let the terse nature of this bug report deture you!



I will assist you with ant additional materials you may need!





PHP Warning:  
file_put_contents(/export/home/tools/php-5.3.5/ext/standard/tests/file/copy_variation4.clean.php):
 failed to open stream: No such file or directory in 
/export/home/tools/php-5.3.5/run-tests.php on line 997

ERROR: Cannot open file 
'/export/home/tools/php-5.3.5/ext/standard/tests/file/copy_variation4.clean.php'
 (save_text)



Test script:
---
None







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

Bug #54943 [Opn->Bgs]: Array_merge links resulting array to source arrays by reference.

[dsp]

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

 ID: 54943
 Updated by: d...@php.net
 Reported by:dtrenz at gmail dot com
 Summary:Array_merge links resulting array to source arrays
 by reference.
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   Mac OSX
 PHP Version:5.3.6
 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

they both hold the same reference:



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


Previous Comments:

[2011-05-27 19:41:16] dtrenz at gmail dot com

Description:

When using array_merge() on an array of objects, the resulting array is linked 
to 

the source array(s) as if passed by reference so that modifying the resulting 

array after the merge ALSO modifies the source array.

Test script:
---
name = 'Bob';



$arrA = array();

$arrB = array($obj); // name = "Bob"



$arrA = array_merge($arrA, $arrB);



// Change name property of first element

$arrA[0]->name = 'Joe';



print_r($arrA);  // name = "Joe"

print_r($arrB);  // name = "Joe"; source array was modified, should still be 
"Bob

Expected result:

Array

(

[0] => stdClass Object

(

[name] => Joe

)

 

)



Array

(

[0] => stdClass Object

(

[name] => Bob

)

 

)

Actual result:
--
Array

(

[0] => stdClass Object

(

[name] => Joe

)

 

)



Array

(

[0] => stdClass Object

(

[name] => Joe

)

 

)






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

Bug #55000 [Opn->Bgs]: instanceof should fail compile-time if checking for non existant class

[dsp]

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

 ID: 55000
 Updated by: d...@php.net
 Reported by:lenar at city dot ee
 Summary:instanceof should fail compile-time if checking for
 non existant class
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.6
 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 expected behavior. You can do something like



http://bugs.php.net/bug.php?id=55000&edit=1

Bug #53338 [Asn]: DTrace build config broken by Rev 305329

[dsp]

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

 ID: 53338
 Updated by: d...@php.net
 Reported by:mike at harschsystems dot com
 Summary:DTrace build config broken by Rev 305329
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Solaris and OS X
 PHP Version:trunk-SVN-2010-11-18 (snap)
 Assigned To:jani
 Block user comment: N
 Private report: N

 New Comment:

1) So providerdesc.o is only build and linked with when under Solaris?



yes because dtrace on Solaris generates stubs that need to be compiled
in. On Mac 

OS the necessary switch to generate providerdesc.o doesn't exist on Mac
OS.


Previous Comments:

[2010-11-18 11:11:38] j...@php.net

Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revision&revision=305487
Log: - Fixed DTrace support in MacOSX (bug #53338)


[2010-11-18 09:53:03] j...@php.net

1) So providerdesc.o is only build and linked with when under Solaris? 

2) What in Makefile did depend on the header file before it was created?


3) I need the generated Makefile you got with current trunk (without
your patch!)


[2010-11-18 09:44:09] j...@php.net

Me break, me fix. :)


[2010-11-18 06:39:42] mike at harschsystems dot com

I can't seem to upload the patch file.  Please refer to the patch file
contents 

here:

http://pastebin.com/SZnvz3L0


[2010-11-18 06:30:14] mike at harschsystems dot com

Description:

The changes made in Rev 305329 break the --enable-dtrace configuration
option on 

both Solaris and OS X.  



The main problems I was able to identify are:



1.) The steps required to build DTrace-enabled binaries are different on
Solaris 

and OS X (see references below).  305329 removed the platform check that
allowed 

OS X to bypass the extra linking step required by Solaris (dtrace -G -s
...).



2.) The generation of the DTrace header file (zend_dtrace_gen.h via
'dtrace -h 

...') was moved to Makefile (from configure) - this broke various
targets that 

depended on the header file prior to it's generation (late in the
Makefile).



3.) A typo (I think) in the path variable used to generate the DTrace
targets 

injected junk into the pathnames, breaking the build.



The included patch file "dtrace_build.patch" may be applied to Rev
305455 to 

resolve these issues.  It essentially re-enlists some of the
functionality that 

existed prior to 305329.  This has been tested on both OS X and
Solaris.



Examples of how to build DTrace USDT probes on Solaris, see:

http://dtrace.org/blogs/ahl/2006/05/08/user-land-tracing-gets-better-and-better/

and

http://blogs.sun.com/dap/entry/writing_a_dtrace_usdt_provider



For the relevant documentation on OS X, see the dtrace(1M) man page:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/

man1/dtrace.1.html





Expected result:

--enable-dtrace should configure and build on platforms that have DTrace
(Solaris 

and OS X - maybe FreeBSD?)

Actual result:
--
--enable-dtrace fails on both platforms for the reasons mentioned in the


Description section.






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

Bug #50947 [Asn->Opn]: crypt() crashes with Apache module but not on command line

[dsp]

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

 ID: 50947
 Updated by: d...@php.net
 Reported by:dax at enst dot fr
 Summary:crypt() crashes with Apache module but not on
 command line
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:Apache2 related
 Operating System:   Solaris10
 PHP Version:5.2.12
-Assigned To:    dsp
+Assigned To:
 Block user comment: N

 New Comment:

I do not have access to Solaris10 machines anymore.


Previous Comments:

[2010-08-26 21:30:58] dax at enst dot fr

The same bug occured with php-5.2.13 and still with php-5.2.14

not with php-5.3.2 and 5.3.3


[2010-02-17 01:13:57] paj...@php.net

Hm no, can't be the same bug. 5.2.12 uses Solaris implementation of
crypt. David, can you look at it pls?


[2010-02-16 23:22:42] paj...@php.net

Duplicate of #51059


[2010-02-08 15:40:10] dax at enst dot fr

# change LD_LIBRARY_PATH for CLI to be thes same as Apache

echo $LD_LIBRARY_PATH 

/usr/local/apache22/lib:/usr/local/apache22/modules:/usr/local/apr/lib:/usr/local/gcc3/lib:/usr/local/lib



is now le same as apache running.



ldd /usr/local/apache22/modules/libphp5.so |sort >ldd-libphp

ldd /usr/local/apache22/bin/php |sort >ldd-cmdphp

diff ldd-cmdphp ldd-libphp

 



CLI is running under root

Apache is running under nobody (as usual)



Same environment about LD_LIBRARY_PATH



mode CLI: both scripts work

mode apache:

   cryptok.php (with salt) works

   cryptbad.php (without salt) crashes


[2010-02-08 15:10:28] johan...@php.net

Can you try using the same LD_LIBRARY_PATH when running CLI as oyur
doing with Apache? Can you check whether ldd reports other libs when
using CLI with this path?



Areyou running CLI and apache as the same user from the same environment
or are there different users/environments used?




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

http://bugs.php.net/bug.php?id=50947


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

Bug #51870 [Opn]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.

[dsp]

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

 ID:   51870
 Updated by:   d...@php.net
 Reported by:  d...@php.net
 Summary:  PDO::fetchAll after a PDO::execute with bindings lead
   to a segv.
 Status:   Open
 Type: Bug
 Package:  PDO related
 Operating System: Mac OS X
 PHP Version:  6SVN-2010-05-20 (SVN)

 New Comment:

Hunting down the bug it seems that 



mysqlnd.collect_memory_statistics = On



causes troubles.


Previous Comments:

[2010-05-20 13:46:45] d...@php.net

Sorry I forgot to add my configure:



'./configure' \

'--with-mysql=mysqlnd' \

'--with-pdo-mysql=mysqlnd' \


[2010-05-20 13:43:54] m...@php.net

erm, this should have been http://snaps.php.net/php-trunk-latest.tar.gz


[2010-05-20 13:42:38] m...@php.net

Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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




[2010-05-20 11:44:53] d...@php.net

Description:

#0  0x7fff83c74886 in __kill ()

#1  0x7fff83d14eae in abort ()

#2  0x7fff83c2ca75 in free ()

#3  0x0001001b8328 in pdo_mysql_stmt_fetch (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo_mysql/mysql_statement.c:655

#4  0x0001001ac47a in do_fetch_common (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0, do_bind=1) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:694

#5  0x0001001adaa1 in do_fetch (stmt=0x100d3ef18, do_bind=1, 

return_value=0x100d4eff8, how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT,
offset=0, 

return_all=0x0) at /Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:861

#6  0x0001001b0388 in zim_PDOStatement_fetchAll (ht=0, 

return_value=0x100d3f888, return_value_ptr=0x0, this_ptr=0x100d3a120, 

return_value_used=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:1560

#7  0x000100465e48 in execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_execute.c:1468

#8  0x0001004176d7 in dtrace_execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:99

#9  0x000100467b04 in zend_do_fcall_common_helper_SPEC 

(execute_data=0x101b2a080) at zend_vm_execute.h:359

#10 0x000100468eeb in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 

(execute_data=0x101b2a080) at zend_vm_execute.h:467

#11 0x0001004663af in execute (op_array=0x100d3c030) at 

zend_vm_execute.h:129

#12 0x0001004175e2 in dtrace_execute (op_array=0x100d3c030) at 

/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:75

#13 0x00010042fb2d in zend_execute_scripts (type=8, retval=0x0, 

file_count=3) at /Users/dsp/dev/c/php/trunk/Zend/zend.c:1210

#14 0x0001003a31fd in php_execute_script
(primary_file=0x7fff5fbfe9f0) at 

/Users/dsp/dev/c/php/trunk/main/main.c:2324

#15 0x00010056caf4 in main (argc=2, argv=0x7fff5fbfeb98) at 

/Users/dsp/dev/c/php/trunk/sapi/cli/php_cli.c:1200

Test script:
---
prepare('SELECT * FROM user WHERE host = ?');

$stm->execute(array('localhost'));

$stm->fetchAll();

Actual result:
--
php(63324) malloc: *** error for object 0x101c849a8: pointer being freed
was not 

allocated

*** set a breakpoint in malloc_error_break to debug

[1]63324 abort  php test.php






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

Bug #51870 [Fbk->Opn]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.

[dsp]

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

 ID:   51870
 Updated by:   d...@php.net
 Reported by:  d...@php.net
 Summary:  PDO::fetchAll after a PDO::execute with bindings lead
   to a segv.
-Status:   Feedback
+Status:   Open
 Type: Bug
 Package:  PDO related
 Operating System: Mac OS X
 PHP Version:  6SVN-2010-05-20 (SVN)



Previous Comments:

[2010-05-20 13:46:45] d...@php.net

Sorry I forgot to add my configure:



'./configure' \

'--with-mysql=mysqlnd' \

'--with-pdo-mysql=mysqlnd' \


[2010-05-20 13:43:54] m...@php.net

erm, this should have been http://snaps.php.net/php-trunk-latest.tar.gz


[2010-05-20 13:42:38] m...@php.net

Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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




[2010-05-20 11:44:53] d...@php.net

Description:

#0  0x7fff83c74886 in __kill ()

#1  0x7fff83d14eae in abort ()

#2  0x7fff83c2ca75 in free ()

#3  0x0001001b8328 in pdo_mysql_stmt_fetch (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo_mysql/mysql_statement.c:655

#4  0x0001001ac47a in do_fetch_common (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0, do_bind=1) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:694

#5  0x0001001adaa1 in do_fetch (stmt=0x100d3ef18, do_bind=1, 

return_value=0x100d4eff8, how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT,
offset=0, 

return_all=0x0) at /Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:861

#6  0x0001001b0388 in zim_PDOStatement_fetchAll (ht=0, 

return_value=0x100d3f888, return_value_ptr=0x0, this_ptr=0x100d3a120, 

return_value_used=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:1560

#7  0x000100465e48 in execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_execute.c:1468

#8  0x0001004176d7 in dtrace_execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:99

#9  0x000100467b04 in zend_do_fcall_common_helper_SPEC 

(execute_data=0x101b2a080) at zend_vm_execute.h:359

#10 0x000100468eeb in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 

(execute_data=0x101b2a080) at zend_vm_execute.h:467

#11 0x0001004663af in execute (op_array=0x100d3c030) at 

zend_vm_execute.h:129

#12 0x0001004175e2 in dtrace_execute (op_array=0x100d3c030) at 

/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:75

#13 0x00010042fb2d in zend_execute_scripts (type=8, retval=0x0, 

file_count=3) at /Users/dsp/dev/c/php/trunk/Zend/zend.c:1210

#14 0x0001003a31fd in php_execute_script
(primary_file=0x7fff5fbfe9f0) at 

/Users/dsp/dev/c/php/trunk/main/main.c:2324

#15 0x00010056caf4 in main (argc=2, argv=0x7fff5fbfeb98) at 

/Users/dsp/dev/c/php/trunk/sapi/cli/php_cli.c:1200

Test script:
---
prepare('SELECT * FROM user WHERE host = ?');

$stm->execute(array('localhost'));

$stm->fetchAll();

Actual result:
--
php(63324) malloc: *** error for object 0x101c849a8: pointer being freed
was not 

allocated

*** set a breakpoint in malloc_error_break to debug

[1]63324 abort  php test.php






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

Bug #51870 [Fbk]: PDO::fetchAll after a PDO::execute with bindings lead to a segv.

[dsp]

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

 ID:   51870
 Updated by:   d...@php.net
 Reported by:  d...@php.net
 Summary:  PDO::fetchAll after a PDO::execute with bindings lead
   to a segv.
 Status:   Feedback
 Type: Bug
 Package:  PDO related
 Operating System: Mac OS X
 PHP Version:  6SVN-2010-05-20 (SVN)

 New Comment:

Sorry I forgot to add my configure:



'./configure' \

'--with-mysql=mysqlnd' \

'--with-pdo-mysql=mysqlnd' \


Previous Comments:

[2010-05-20 13:43:54] m...@php.net

erm, this should have been http://snaps.php.net/php-trunk-latest.tar.gz


[2010-05-20 13:42:38] m...@php.net

Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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




[2010-05-20 11:44:53] d...@php.net

Description:

#0  0x7fff83c74886 in __kill ()

#1  0x7fff83d14eae in abort ()

#2  0x7fff83c2ca75 in free ()

#3  0x0001001b8328 in pdo_mysql_stmt_fetch (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo_mysql/mysql_statement.c:655

#4  0x0001001ac47a in do_fetch_common (stmt=0x100d3ef18, 

ori=PDO_FETCH_ORI_NEXT, offset=0, do_bind=1) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:694

#5  0x0001001adaa1 in do_fetch (stmt=0x100d3ef18, do_bind=1, 

return_value=0x100d4eff8, how=PDO_FETCH_BOTH, ori=PDO_FETCH_ORI_NEXT,
offset=0, 

return_all=0x0) at /Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:861

#6  0x0001001b0388 in zim_PDOStatement_fetchAll (ht=0, 

return_value=0x100d3f888, return_value_ptr=0x0, this_ptr=0x100d3a120, 

return_value_used=0) at 

/Users/dsp/dev/c/php/trunk/ext/pdo/pdo_stmt.c:1560

#7  0x000100465e48 in execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_execute.c:1468

#8  0x0001004176d7 in dtrace_execute_internal
(execute_data_ptr=0x101b2a080, 

return_value_used=0) at
/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:99

#9  0x000100467b04 in zend_do_fcall_common_helper_SPEC 

(execute_data=0x101b2a080) at zend_vm_execute.h:359

#10 0x000100468eeb in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 

(execute_data=0x101b2a080) at zend_vm_execute.h:467

#11 0x0001004663af in execute (op_array=0x100d3c030) at 

zend_vm_execute.h:129

#12 0x0001004175e2 in dtrace_execute (op_array=0x100d3c030) at 

/Users/dsp/dev/c/php/trunk/Zend/zend_dtrace.c:75

#13 0x00010042fb2d in zend_execute_scripts (type=8, retval=0x0, 

file_count=3) at /Users/dsp/dev/c/php/trunk/Zend/zend.c:1210

#14 0x0001003a31fd in php_execute_script
(primary_file=0x7fff5fbfe9f0) at 

/Users/dsp/dev/c/php/trunk/main/main.c:2324

#15 0x00010056caf4 in main (argc=2, argv=0x7fff5fbfeb98) at 

/Users/dsp/dev/c/php/trunk/sapi/cli/php_cli.c:1200

Test script:
---
prepare('SELECT * FROM user WHERE host = ?');

$stm->execute(array('localhost'));

$stm->fetchAll();

Actual result:
--
php(63324) malloc: *** error for object 0x101c849a8: pointer being freed
was not 

allocated

*** set a breakpoint in malloc_error_break to debug

[1]63324 abort  php test.php






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

#50496 [Opn]: Use of is valid only in a c99 compilation environment.

[dsp]

 ID:   50496
 Updated by:   d...@php.net
 Reported By:  alexander at skwar dot name
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Solaris 10, Sparc
 PHP Version:  5.3SVN-2009-12-16 (snap)
 Assigned To:  srinatar
 New Comment:

Opening again the bug as it's not fixed yet.


Previous Comments:


[2010-01-11 15:41:41] johan...@php.net

Reopening - seems to still be broken.



[2010-01-11 15:06:39] d...@php.net

The problem is not gcc but libc. If the libc is strict with what the
ISO 
standard defines you cannot use c99 headers in non c99 code. So we have

to either add c99/_STD_C99 globally or get rid of the c99 code. You can

compile it with gcc and SUN libc and you will get the same error. GNU 
libc seems not to make this difference, which is why it works.



[2009-12-17 05:37:33] alexander at skwar dot name

Nö, it is not a Sun Studio Compiler issue - if you compile using gcc 
3.4.3 from /usr/sfw/bin, you will run into the same problems. At 
least on Solaris 10.



[2009-12-16 22:48:58] srina...@php.net

on other platforms like HP-UX and AIX as well as gcc, these types
(bool, 
true,false) are defined by simply including the header file. these 
platforms do not require c99 standard to be defined as pre-requisite to

define these macros. 

at this moment, this seems to be solaris sun studio compiler only
issue. 




[2009-12-16 21:33:21] s...@php.net

Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=292223
Log: - Fix NEWS for bug #50496
# Update NEWS to keep resolved bugs in decreasing order (Christopher
Jones)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50496

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

#50496 [Csd]: Use of is valid only in a c99 compilation environment.

[dsp]

 ID:   50496
 Updated by:   d...@php.net
 Reported By:  alexander at skwar dot name
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Solaris 10, Sparc
 PHP Version:  5.3SVN-2009-12-16 (snap)
 Assigned To:  srinatar
 New Comment:

The problem is not gcc but libc. If the libc is strict with what the
ISO 
standard defines you cannot use c99 headers in non c99 code. So we have

to either add c99/_STD_C99 globally or get rid of the c99 code. You can

compile it with gcc and SUN libc and you will get the same error. GNU 
libc seems not to make this difference, which is why it works.


Previous Comments:


[2009-12-17 05:37:33] alexander at skwar dot name

Nö, it is not a Sun Studio Compiler issue - if you compile using gcc 
3.4.3 from /usr/sfw/bin, you will run into the same problems. At 
least on Solaris 10.



[2009-12-16 22:48:58] srina...@php.net

on other platforms like HP-UX and AIX as well as gcc, these types
(bool, 
true,false) are defined by simply including the header file. these 
platforms do not require c99 standard to be defined as pre-requisite to

define these macros. 

at this moment, this seems to be solaris sun studio compiler only
issue. 




[2009-12-16 21:33:21] s...@php.net

Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=292223
Log: - Fix NEWS for bug #50496
# Update NEWS to keep resolved bugs in decreasing order (Christopher
Jones)



[2009-12-16 21:10:11] paj...@php.net

Pls don't open another bug for the exact same problem.

If the header is only available in c99 and c99 can have bad side
effects, why not define manually on Solaris what is necessary for the
code to work and be done with this problem?



[2009-12-16 20:50:29] srina...@php.net

[ see also bug #50497 ] 

thanks for taking time to report this issue. the fix for this issue is

now integrated. mean while, your suggested work around (export
CFLAGS=-
xc99=all) should be acceptable. 

- Sriram





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/50496

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

#49938 [Ana->Csd]: Phar::isBuffering() returns inverted value

[dsp]

 ID:   49938
 Updated by:   d...@php.net
 Reported By:  nodkz at mail dot ru
-Status:   Analyzed
+Status:   Closed
 Bug Type: PHAR related
 Operating System: Windows XP
 PHP Version:  5.3.1RC2
 Assigned To:  cellog
 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:


[2009-11-13 00:58:12] s...@php.net

Automatic comment from SVN on behalf of cellog
Revision: http://svn.php.net/viewvc/?view=revision&revision=290647
Log: fix PHP Bug #49938: Phar::isBuffering() returns inverted value



[2009-11-13 00:16:11] cel...@php.net

The only bug is that Phar::isBuffering() has its values inverted.

It is not performant to use the buffering feature for extremely large
phar archives.  Instead, use this code:

buildFromDirectory(__DIR__ . '/fillit');
$b = time(true);
echo "done in ", $b - $a, " seconds\n";
echo count($phar),"\n";
?>

I get 10 files added in approximately 118 seconds.  The code you
supplied takes well over that just for the first 1 files.




[2009-10-21 07:57:23] nodkz at mail dot ru

Description:

I need add 100 000 files to phar arhive.
First 1000 files insert very quick. But when I insert from 9000 to
1, it works about 20 minutes.

I found that every changes writes to disk. In documentation I so
buffering operation to maket set of change, before writing to disk. If I
run startBuffering()/stopBuffering() commands.

So I try to run startBuffering() on PHP 5.2.11 - it doesn't work.
So I install PHP5.3.1RC2 - it doesn't work again.

Reproduce code:
---
$phar = new Phar('test.phar');
$phar->startBuffering();
var_dump($phar->isBuffering());

for($i=0;$i<10;$i++) {
   // write data in files  XXX/XXX.txt
   $phar->addFromString( floor($i/1000).'/'.($i%1000).'txt', 'some
data');
}
$phar->stopBuffering();

Expected result:

Expect to see
   bool(true)



Actual result:
--
But scripts shows: 
   bool(false)





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

#50283 [Opn->Tbd]: allow base in gmp_strval to use full range: 2 to 62, and -2 to -36

[dsp]

 ID:   50283
 Updated by:   d...@php.net
 Reported By:  asphp at dsgml dot com
-Status:   Open
+Status:   To be documented
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

The documentation states that base has to be between 2 and 36. We have
to correct this, as we now allow -2 to -36 aswell.


Previous Comments:


[2009-11-24 13:33:36] s...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=291262
Log: Implement feature request #50283 (allow base in gmp_strval to use
full range: 2 to 62, and -2 to -36)



[2009-11-24 11:31:47] asphp at dsgml dot com

And for input as well of course.



[2009-11-24 11:29:58] asphp at dsgml dot com

Description:

According to http://gmplib.org/manual/Converting-Integers.html
gmp_strval should be able to use a base range of 2 to 62, and -2 to
-36.

However php enforces the base to be between 2 and 36. Please allow the
full range.






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

#49301 [Opn->Fbk]: HAVE_GLOB is not detected correctly

[dsp]

 ID:   49301
 Updated by:   d...@php.net
 Reported By:  php at stefan-marr dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.6
 PHP Version:  6SVN-2009-08-19 (SVN)
 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php6.0-latest.tar.gz
 
For Windows:

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




Previous Comments:


[2009-08-19 20:46:53] php at stefan-marr dot de

Description:

Seems like HAVE_GLOB is not set correctly by I guess configure.
It is needed to be set in main/streams/glob_wrapper.c to be able to 
compile






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

#49142 [Csd]: crash when exception thrown from __tostring() (PHP_5_3 only!)

[dsp]

 ID:   49142
 Updated by:   d...@php.net
 Reported By:  ies_clan at hotmail dot com
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: *
 PHP Version:  5.3 (2009-08-04)
 Assigned To:  dsp
 New Comment:

Wrong comment before, sorry.

Fixed in SVN.


Previous Comments:


[2009-10-27 13:10:09] d...@php.net

Please try using this snapshot:

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

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





[2009-10-27 13:02:37] s...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=289987
Log: - Fixed bug #49142 (crash when exception thrown from __tostring())



[2009-08-03 22:27:52] j...@php.net

Program received signal SIGSEGV, Segmentation fault.
zend_hash_num_elements (ht=0x8e05b50) at /home/jani/src/php-
5.3/Zend/zend_hash.c:1014
1014{
(gdb) bt
#0  zend_hash_num_elements (ht=0x8e05b50) at /home/jani/src/php-
5.3/Zend/zend_hash.c:1014
#1  0x082a3a00 in zend_error (type=148921168, format=0x8716124 "%s") 
at /home/jani/src/php-5.3/Zend/zend_variables.h:45
#2  0x08254a7a in php_verror (docref=0x0, params=0x83723ec "", type=2,
format=0x86eb0dc "Failed to write session data (%s). Please verify

that the current setting of session.save_path is correct (%s)",
args=0xbfe5ed9c "3\204n\b�#7\b\"") at /home/jani/src/php-
5.3/main/main.c:794
#3  0x08254f51 in php_error_docref0 (docref=0x0, type=2,
format=0x86eb0dc "Failed to write session data (%s). Please verify

that the current setting of session.save_path is correct (%s)")
at /home/jani/src/php-5.3/main/main.c:806
#4  0x0817fff5 in php_session_flush () at /home/jani/src/php-
5.3/ext/session/session.c:598
#5  0x08180281 in zm_deactivate_session (type=1, module_number=22) at 
/home/jani/src/php-5.3/ext/session/session.c:2138
#6  0x082a4310 in module_registry_cleanup (module=0x8ceb6e8) at 
/home/jani/src/php-5.3/Zend/zend_API.c:2150
#7  0x082adb84 in zend_hash_reverse_apply (ht=0x8757600, 
apply_func=0x82a42f0 )
at /home/jani/src/php-5.3/Zend/zend_hash.c:755
#8  0x082a2a19 in zend_deactivate_modules () at /home/jani/src/php-
5.3/Zend/zend.c:866
#9  0x0825360a in php_request_shutdown (dummy=0x0) at 
/home/jani/src/php-5.3/main/main.c:1565
#10 0x08321224 in main (argc=3, argv=0xbfe5f374) at 
/home/jani/src/php-5.3/sapi/cli/php_cli.c:1369




[2009-08-03 22:27:12] j...@php.net

Reduced reproduce script:

http://www.immunecellcompetence.com/exceptionBug.zip

in the root dir is a sql file.
u have to edit the exceptionBug\Engine\Configuration\Password.Inc.php
file.

after that, u can start it.

if u see the login page, klick on the link: Login mit EnemyArea und
test

sometimes often, until u got loged in. then klick on the next link:
EnemyArea

and the apache will crash with the following msg: unbehandelte ausnahme
in httpd.exe [4624]

to fix it you have to go into the
MKLF\System\Engine\StyleSheet.class.php

the line //use MKLF\System\Engine\Exceptions\SystemException; is the
problem.

if u comment that in, it will work.






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

#49142 [Ver->Csd]: crash when exception thrown from __tostring() (PHP_5_3 only!)

[dsp]

 ID:   49142
 Updated by:   d...@php.net
 Reported By:  ies_clan at hotmail dot com
-Status:   Verified
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: *
 PHP Version:  5.3 (2009-08-04)
 Assigned To:  dsp
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-10-27 13:02:37] s...@php.net

Automatic comment from SVN on behalf of dsp
Revision: http://svn.php.net/viewvc/?view=revision&revision=289987
Log: - Fixed bug #49142 (crash when exception thrown from __tostring())



[2009-08-03 22:27:52] j...@php.net

Program received signal SIGSEGV, Segmentation fault.
zend_hash_num_elements (ht=0x8e05b50) at /home/jani/src/php-
5.3/Zend/zend_hash.c:1014
1014{
(gdb) bt
#0  zend_hash_num_elements (ht=0x8e05b50) at /home/jani/src/php-
5.3/Zend/zend_hash.c:1014
#1  0x082a3a00 in zend_error (type=148921168, format=0x8716124 "%s") 
at /home/jani/src/php-5.3/Zend/zend_variables.h:45
#2  0x08254a7a in php_verror (docref=0x0, params=0x83723ec "", type=2,
format=0x86eb0dc "Failed to write session data (%s). Please verify

that the current setting of session.save_path is correct (%s)",
args=0xbfe5ed9c "3\204n\b�#7\b\"") at /home/jani/src/php-
5.3/main/main.c:794
#3  0x08254f51 in php_error_docref0 (docref=0x0, type=2,
format=0x86eb0dc "Failed to write session data (%s). Please verify

that the current setting of session.save_path is correct (%s)")
at /home/jani/src/php-5.3/main/main.c:806
#4  0x0817fff5 in php_session_flush () at /home/jani/src/php-
5.3/ext/session/session.c:598
#5  0x08180281 in zm_deactivate_session (type=1, module_number=22) at 
/home/jani/src/php-5.3/ext/session/session.c:2138
#6  0x082a4310 in module_registry_cleanup (module=0x8ceb6e8) at 
/home/jani/src/php-5.3/Zend/zend_API.c:2150
#7  0x082adb84 in zend_hash_reverse_apply (ht=0x8757600, 
apply_func=0x82a42f0 )
at /home/jani/src/php-5.3/Zend/zend_hash.c:755
#8  0x082a2a19 in zend_deactivate_modules () at /home/jani/src/php-
5.3/Zend/zend.c:866
#9  0x0825360a in php_request_shutdown (dummy=0x0) at 
/home/jani/src/php-5.3/main/main.c:1565
#10 0x08321224 in main (argc=3, argv=0xbfe5f374) at 
/home/jani/src/php-5.3/sapi/cli/php_cli.c:1369




[2009-08-03 22:27:12] j...@php.net

Reduced reproduce script:

http://www.immunecellcompetence.com/exceptionBug.zip

in the root dir is a sql file.
u have to edit the exceptionBug\Engine\Configuration\Password.Inc.php
file.

after that, u can start it.

if u see the login page, klick on the link: Login mit EnemyArea und
test

sometimes often, until u got loged in. then klick on the next link:
EnemyArea

and the apache will crash with the following msg: unbehandelte ausnahme
in httpd.exe [4624]

to fix it you have to go into the
MKLF\System\Engine\StyleSheet.class.php

the line //use MKLF\System\Engine\Exceptions\SystemException; is the
problem.

if u comment that in, it will work.






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

#50010 [Opn->Csd]: script produces a bus error

[dsp]

 ID:   50010
 Updated by:   d...@php.net
 Reported By:  rick at alpinenetworking dot com
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Mac OS X 10.5.8
 PHP Version:  5.3.0
 New Comment:

Same problem as #49142


Previous Comments:


[2009-10-27 07:51:01] rick at alpinenetworking dot com

Description:

The script below gives me the following error in my error logs:

[Tue Oct 27 01:34:20 2009] [notice] child pid 28231 exit signal Bus 
error (10)

When I run the same script on Mac OS X 10.6.1 with the version of PHP 
that ships with the OS I get the following:

[Tue Oct 27 01:17:35 2009] [notice] child pid 2536 exit signal 
Segmentation fault (11)

The code at the URL below is as small as I could get it.  It's 35 lines

and if I take out any part of it then I the segfault/bus error stops 
occurring.


Reproduce code:
---
http://pastie.org/671293






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

#48668 [Asn->Ctl]: foreach with array will coredump php

[dsp]

 ID:   48668
 Updated by:   d...@php.net
 Reported By:  dmda at yandex dot ru
-Status:   Assigned
+Status:   Critical
 Bug Type: Reproducible crash
 Operating System: Solaris
 PHP Version:  5.3.0RC4
 Assigned To:  dsp
 New Comment:

PHP is broken on Sparc (and possible every other processor that
requires memalignment) at the moment


Previous Comments:


[2009-06-26 15:42:15] d...@php.net

It looks like this is a memalign issue. PHP 5.3.0 is now build with 
flags to avoid the crash. I assign the bug to me to provide a proper
fix 
for the issue for 5.3.1



[2009-06-24 12:21:10] johan...@php.net

When using --enable-dbug the code works, without --enable-debug the
code fails, maybe that's the reason why I didn't see this before.

uname -a
SunOS techra46 5.8 Generic_117350-54 sun4u sparc SUNW,Sun-Fire-V210

The issue seems to be independent from the compiler but in some way
system dependent, another similar box worked for me.



[2009-06-24 06:49:42] dmda at yandex dot ru

to me it looks like bogus pointer appeared in the heap's cache first,
then it was returned by the allocator, called by ALLOC_ZVAL(). I see no
other reasons for the tmp pointer to have this strange value.



[2009-06-24 00:32:54] scott...@php.net

Don't think its endian specific, PPC chip works.

Will test with another sparc box shortly.



[2009-06-23 22:16:22] dmda at yandex dot ru

Description:

$uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine
$ sapi/cli/php ./1.php
Bus Error (core dumped)
$gdb --core core sapi/cli/php

Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0  0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at 
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0  0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at 
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1  0x002d92a0 in execute (op_array=0x70bd90)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2  0x002b8d48 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3  0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4  0x003447d4 in main (argc=2, argv=0xffbefcac)
at
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str =
{val = 
0x71ce70 "",
  len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers =
0x0}}, 
refcount__gc = 0,
  type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2



Reproduce code:
---
$cat 1.php
 







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

#48695 [Opn->Asn]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble

[dsp]

 ID:   48695
 Updated by:   d...@php.net
 Reported By:  allerlei+bugs dot php dot net at sihw dot nl
-Status:   Open
+Status:   Assigned
 Bug Type: CGI related
 Operating System: Centos 4/5
 PHP Version:  5.2.10
-Assigned To:  
+Assigned To:  srinatar


Previous Comments:


[2009-07-07 00:09:00] sriram dot natarajan at gmail dot com

ok, i compiled cgiwrap 4.1 with the following settings.

./configure
'--with-php=/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210'
'--with-httpd-user=sriramn' '--with-php-cgiwrap'
'--with-install-dir=/export/home/sriramn/sun/httpd22/cgi-bin'
'--with-install-group=staff' --with-cgiwrapd --with-php-interpreter


Initializing Logging
Redirecting STDERR to STDOUT

Setting SIGXCPU to default behaviour


Environment Variables:
 QUERY_STRING: ''
  SCRIPT_NAME: '/cgi-bin/php-cgiwrapd'
  SCRIPT_FILENAME:
'/export/home/sriramn/sun/httpd22/cgi-bin/php-cgiwrapd'
 REDIRECT_URL: '/php-cgi/cgi-info.php'
PATH_INFO: '/sriramn/php-cgi/cgi-info.php'
  PATH_TRANSLATED:
'/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php'
  REMOTE_USER: ''
  REMOTE_HOST: ''
  REMOTE_ADDR: '127.0.0.1'


Trying to extract user from PATH_INFO.
Retrieved User Name:  'sriramn'

User Data Retrieved:
 UserID: 'sriramn'
UID: '101'
GID: '10'
   Home Dir: '/export/home/sriramn'
Checking user minimum uid.

Script Base Directory:  '/export/home/sriramn/public_html/cgi-bin'
Fetching script string

Trying to extract script from PATH_INFO
Extracted PATH_INFO '/php-cgi/cgi-info.php'
Building script path

Condensing slashes.

Script Relative Path:  'php-cgi/cgi-info.php'
Script Absolute Path: 
'/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php'
Checking for special interpreted script (php).
Interpreter Path: 
'/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210'

Fixing Environment Variables.

Environment Variables:
 QUERY_STRING: ''
  SCRIPT_NAME:
'/cgi-bin/php-cgiwrapd/sriramn/php-cgi/cgi-info.php'
  SCRIPT_FILENAME:
'/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php'
 REDIRECT_URL: '/php-cgi/cgi-info.php'
PATH_INFO: ''
  PATH_TRANSLATED:
'/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php'
  REMOTE_USER: ''
  REMOTE_HOST: ''
  REMOTE_ADDR: '127.0.0.1'


UIDs/GIDs Changed To:
   RUID: '101'
   EUID: '101'
   RGID: '10'
   EGID: '10'

Changing current directory to
'/export/home/sriramn/public_html/cgi-bin/php-cgi'
Executing: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210'
Arguments:
0: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210'
1: 'cgi-info.php'




Output of script follows:
=
X-Powered-By: PHP/5.2.10
Content-type: text/html

server software Apache/2.2.11 (Unix)
script name /php-cgi/cgi-info.php
script filename
/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php
path info 
path translated 
redirect uri
redirect url/php-cgi/cgi-info.php
self uri is /php-cgi/cgi-info.php

and php 5.2.10 seem to be returning the right output. 

what configuration am i missing ?

fyi, here is how my apache conf looks ..
AddHandler cgi-wrapper .php
AddHandler cgi-wrapper .cgi
Action cgi-wrapper /cgi-bin/php-cgiwrapd/sriramn

what am I missing here ?

i will also hook up SuEXEC and see if I can reproduce that way..



[2009-07-02 14:19:51] allerlei+bugs dot php dot net at sihw dot nl

Probably not easy to reproduce without a wrapper like cgiwrap. I did
not get suexec to work, but if you have an install with suexec handling
php-cgi succesfully, that might work.

Here are the $_SERVER values on my test system with apache. This uses
/spinwebstartscript/startscript/php/USERNAME as a handler for php files.
So the file test.php will be called through the handler
/spinwebstartscript/startscript/php/USERNAME/test.php.

Weird thing is that phpinfo() reports the SCRIPT_NAME environment var
differently. Propably this is after some transformation in the php
process, because the only thing different in the two configurations is
the php version.

The interesting value is SCRIPT_NAME.

This is $_SERVER on 5.2.8:
[REDIRECT_SCRIPT_URL] => /test.php
[REDIRECT_SCRIPT_URI] => http://wensweb/test.php
[REDIRECT_HANDLER] => startscript_php
[REDIRECT_STATUS] => 200
[SCRIPT_URL] => /test.php
[SCRIPT_URI] => http://wensweb/test.php
[HTTP_HOST] => wensweb
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 6.0; nl;
rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
[HTTP_ACCEPT] =>
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[HTTP_ACCEPT_LANGUAGE] => nl-nl,en;q=0.7,fr;q=0.3
[HTTP_ACCEPT_ENCODI

#48668 [Ctl->Ver]: foreach with array will coredump php

[dsp]

 ID:   48668
 Updated by:   d...@php.net
 Reported By:  dmda at yandex dot ru
-Status:   Critical
+Status:   Verified
 Bug Type: Reproducible crash
-Operating System: solaris 8
+Operating System: Solaris
 PHP Version:  5.3.0RC4
-Assigned To:  dmitry
+Assigned To:  dsp
 New Comment:

It looks like this is a memalign issue. PHP 5.3.0 is now build with 
flags to avoid the crash. I assign the bug to me to provide a proper
fix 
for the issue for 5.3.1


Previous Comments:


[2009-06-24 12:21:10] johan...@php.net

When using --enable-dbug the code works, without --enable-debug the
code fails, maybe that's the reason why I didn't see this before.

uname -a
SunOS techra46 5.8 Generic_117350-54 sun4u sparc SUNW,Sun-Fire-V210

The issue seems to be independent from the compiler but in some way
system dependent, another similar box worked for me.



[2009-06-24 06:49:42] dmda at yandex dot ru

to me it looks like bogus pointer appeared in the heap's cache first,
then it was returned by the allocator, called by ALLOC_ZVAL(). I see no
other reasons for the tmp pointer to have this strange value.



[2009-06-24 00:32:54] scott...@php.net

Don't think its endian specific, PPC chip works.

Will test with another sparc box shortly.



[2009-06-23 22:16:22] dmda at yandex dot ru

Description:

$uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine
$ sapi/cli/php ./1.php
Bus Error (core dumped)
$gdb --core core sapi/cli/php

Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0  0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at 
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0  0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at 
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1  0x002d92a0 in execute (op_array=0x70bd90)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2  0x002b8d48 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3  0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4  0x003447d4 in main (argc=2, argv=0xffbefcac)
at
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str =
{val = 
0x71ce70 "",
  len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers =
0x0}}, 
refcount__gc = 0,
  type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2



Reproduce code:
---
$cat 1.php
 







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

#48644 [Opn->Csd]: mysqlnd does not compile with '--enable-mysqlnd-threading'

[dsp]

 ID:   48644
 Updated by:   d...@php.net
 Reported By:  alex dot emsenhuber at bluewin dot ch
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.5.7
 PHP Version:  5.3.0RC4
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2009-06-22 11:53:57] alex dot emsenhuber at bluewin dot ch

Description:

ext/mysqlnd/mysqlnd_result.c does not compile with
'--enable-mysqlnd-threading' in ./configure, removing this option make
PHP compile correctly. This seems to be caused by
http://cvs.php.net/viewvc.cgi/php-src/ext/mysqlnd/mysqlnd_structs.h?r1=1.2.2.19&r2=1.2.2.20
where free_chunck was removed.

Reproduce code:
---
'./configure' \
'--prefix=/usr' \
'--mandir=/usr/share/man' \
'--infodir=/usr/share/info' \
'--sysconfdir=/private/etc' \
'--enable-bcmath' \
'--enable-calendar' \
'--enable-cgi' \
'--enable-cli' \
'--enable-ctype' \
'--enable-dba' \
'--enable-debug' \
'--enable-embedded-mysqli' \
'--enable-exif' \
'--enable-ftp' \
'--enable-gd-native-ttf' \
'--enable-maintainer-zts' \
'--enable-mbstring' \
'--enable-mbregex' \
'--enable-mysqlnd-threading' \
'--enable-pcntl' \
'--enable-sockets' \
'--enable-sqlite-utf8' \
'--enable-wddx' \
'--enable-zend-multibyte' \
'--with-config-file-path=/private/etc' \
'--with-curl=/usr' \
'--with-db4=/usr/local/BerkeleyDB.4.7' \
'--with-gd' \
'--with-imap-ssl' \
'--with-kerberos=/usr' \
'--with-mcrypt' \
'--with-mhash' \
'--with-mysql=mysqlnd' \
'--with-mysql-sock=/private/var/mysql/mysql.sock' \
'--with-mysqli=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
'--with-pdo-pgsql=/Library/PostgreSQL/8.3' \
'--with-pgsql=/Library/PostgreSQL/8.3' \
'--with-readline' \
'--with-snmp' \
'--with-sqlite' \
'--with-tsrm-pthreads' \
'--with-xmlrpc' \
'--with-zlib-dir=/usr' \
'--with-apxs2=/usr/bin/apxs'

make

Expected result:

the file compiles correctly.

Actual result:
--
/Users/alexandre/Downloads/php53/ext/mysqlnd/mysqlnd_result.c: In
function 'mysqlnd_free_background_buffered_data':
/Users/alexandre/Downloads/php53/ext/mysqlnd/mysqlnd_result.c:363:
error: 'struct st_mysqlnd_memory_pool_chunk' has no member named
'free_chunk'





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

#46952 [Asn->Fbk]: mysqlnd compile failure with suncc

[dsp]

 ID:   46952
 Updated by:   d...@php.net
 Reported By:  dg at artegic dot de
-Status:   Assigned
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: Solaris 10
 PHP Version:  5.3CVS-2008-12-27 (snap)
 Assigned To:  mysql
 New Comment:

Please try using this CVS snapshot:

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

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




Previous Comments:


[2008-12-27 11:40:01] dg at artegic dot de

Description:

Using Sun Studio 12 C Compiler including latest bugfixes with Solaris 
10/x86 on a Sun Fire X2200 M2 (2 Dual Core AMD Opteron).

Configure script runs with no failures/warnings. If (and only if) 
using --with-mysql=mysqlnd compiling fails:

/bin/sh .../libtool --silent --preserve-dup-deps --mode=compile cc  -
Iext/mysqlnd/ -I.../ext/mysqlnd/ -DPHP_ATOM_INC -I.../include -
I.../main -I... -I.../ext/ereg/regex -I/opt/csw/include/libxml2 -
I/opt/csw/include -I.../ext/date/lib -I/opt/csw/include/freetype2 -
I.../ext/mbstring/oniguruma -I.../ext/mbstring/libmbfl -
I.../ext/mbstring/libmbfl/mbfl -I/usr/include/libxml2 -I.../TSRM -
I.../Zend  -D_POSIX_PTHREAD_SEMANTICS  -I/opt/csw/include -fsimple=2 -
xnorunpath -xO4 -xalias_level=basic -xipo=1 -xlibmopt -
xprefetch_level=1 -xprefetch=auto -xstrconst -xtarget=native -
zlazyload -DZTS   -c .../ext/mysqlnd/mysqlnd_ps_codec.c -o 
ext/mysqlnd/mysqlnd_ps_codec.lo 
".../ext/mysqlnd/mysqlnd.h", line 372: warning: syntax error:  empty 
declaration
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 82: undefined symbol: 
MYSQLND_LLU_SPEC
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 82: warning: improper 
pointer/integer combination: arg #2
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 90: undefined symbol: 
MYSQLND_LLU_SPEC
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 90: warning: improper 
pointer/integer combination: arg #2
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 111: undefined symbol: 
MYSQLND_LL_SPEC
".../ext/mysqlnd/mysqlnd_ps_codec.c", line 111: warning: improper 
pointer/integer combination: arg #2
cc: acomp failed for .../ext/mysqlnd/mysqlnd_ps_codec.c
*** Error code 1
make: Fatal error: Command failed for target 
`ext/mysqlnd/mysqlnd_ps_codec.lo'







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

#47675 [Opn->Fbk]: File descriptor leaked due to HAVE_BROKEN_GETCWD

[dsp]

 ID:   47675
 Updated by:   d...@php.net
 Reported By:  cs at ecn dot purdue dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Solaris 10
 PHP Version:  5.2.9
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


I run OpenSolaris 2009.06 with Apache 2.2.11 and cannot reproduce this

behavior. The old_cwd_fd is closed. ZEND_EXIT calls zend_bailout which

jumps back to the end of the try/catch block in php_execute_script
where 
the descriptor is closed.

Can you be more specific about the behavior you encountered?




Previous Comments:


[2009-03-16 16:25:21] cs at ecn dot purdue dot edu

I am using apache 2.2.11.



[2009-03-16 16:21:51] j...@php.net

Apache1 or Apache2 ?



[2009-03-16 14:07:47] cs at ecn dot purdue dot edu

Description:

mod_php contains a potential file descriptor leak on Solaris 10 when 
script executes "exit()".

Reproduce code:
---


The change in behavior is due to the addition of HAVE_BROKEN_GETCWD for
Solaris 10. In php_execute_script, a file descriptor is opened to hold
the current working directory, but is not closed in the case where php
code may not return to this function after executing a script. mod_php
isn't aware of the resource that was allocated and not freed.

Expected result:

Normally web server runs for days without resource trouble. In the 
case where a PHP script does an "exit(0)", the web server will run 
out of file descriptors and will need restarting.






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

#48535 [Opn->Bgs]: file_exists returns false if the file path is a symlink

[dsp]

 ID:   48535
 Updated by:   d...@php.net
 Reported By:  tobias dot burger at rolmail dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows Server 2008
 PHP Version:  5.3.0RC3
 New Comment:

Please check if you have the correct permissions.


Previous Comments:


[2009-06-12 08:00:29] tobias dot burger at rolmail dot net

Correction: file_exists does ALWAYS return false, even for normal file
pathes



[2009-06-12 07:32:37] tobias dot burger at rolmail dot net

Description:

file_exists returns false if the file path is a symlink

Reproduce code:
---
# d:\myfolder\test.php
> mklink /D c:\inetpub\wwwroot\myfolder d:\myfolder

file_exists('c:\inetpub\wwwroot\myfolder\test.php')


Expected result:

true

Actual result:
--
false





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

#47042 [Opn->Csd]: cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache

[dsp]

 ID:   47042
 Updated by:   d...@php.net
 Reported By:  sriram dot natarajan at sun dot com
-Status:   Open
+Status:   Closed
 Bug Type: CGI related
 Operating System: linux , solaris
 PHP Version:  5.2.9
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2009-06-09 00:39:08] php at dzm dot com

I can verify that Sriram's patch works correctly (13-Mar) on a patched
PHP 5.2.9 FCGI on Fedora 10.

Can anyone validate this for Windows/IIS and get this into PHP 5.2.10?



[2009-05-09 18:40:02] php at dzm dot com

This behavior remains broken in PHP 5.2.9. Is there any chance at all
of the patch being integrated into 5.2.10?



[2009-03-16 23:55:37] j...@php.net

See also bug #47625



[2009-03-13 00:10:22] sriram dot natarajan at sun dot com

hi
 this fix is not available with the latest php snapshot. my latest
patch needs to be looked into and considered fixing it for 5.3 as well
as 5.2.9

[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG  Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c   Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}

if (env_path_translated != NULL &&
env_redirect_url != NULL &&
-   orig_script_filename != NULL &&
script_path_translated != NULL) {
+   env_path_translated !=
script_path_translated &&
+   strcmp(env_path_translated,
script_path_translated) != 0) {
/* 
   pretty much apache specific.  If we
have a redirect_url
   then our script_filename and
script_name point to the

thanks
sriram



[2009-03-03 09:56:55] sriram dot natarajan at sun dot com

i have tested this patch with apache 2.0 and 2.2 configurations within
cgi and was able to get applications like joomla working fine.

can some one kindly look into the attached patch and provide your
feedback

thanks



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47042

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

#47871 [Opn]: PHPIniScanDir directive for apache allows scanning for extension ini files

[dsp]

 ID:   47871
 Updated by:   d...@php.net
 Reported By:  sriram dot natarajan at gmail dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: unix and linux
 PHP Version:  5.3.0RC1
-Assigned To:  
+Assigned To:  dsp
 New Comment:

I think that's a good one. I assign it to me so that we don't forget
about that one.


Previous Comments:


[2009-04-02 02:47:47] sriram dot natarajan at gmail dot com

hi
 here is the patch to address this issue
http://cr.opensolaris.org/~sn123202/php53-47871.patch
http://cr.opensolaris.org/~sn123202/php52-47871.patch

let me know with your comments..



[2009-04-02 02:28:41] sriram dot natarajan at gmail dot com

Description:

Provide PHPIniScanDir directive similar to PHPIniDir for apache. this
directive can perform the functionality of PHP_INI_SCAN_DIR environment
variable. 

for more information on what PHP_INI_SCAN_DIR, please refer to bug
http://bugs.php.net/bug.php?id=45114

Expected result:

PHPIniScanDir directive should be accepted and php should load
extension specific ini files from this location






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

#47663 [Opn->Bgs]: dcngettext() crashes if count parameter is negative

[dsp]

 ID:   47663
 Updated by:   d...@php.net
 Reported By:  d...@php.net
-Status:   Open
+Status:   Bogus
 Bug Type: Gettext related
 Operating System: OpenSolaris 2009.11
 PHP Version:  5.2.9
 New Comment:

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

Thank you for your interest in PHP.

The bug was reported to the opensolaris community. Its a bug in their
gettext 
implementation and not in phps wrapper


Previous Comments:


[2009-04-14 09:20:59] j...@php.net

Note: Linux glibc gettext implementation does not crash..



[2009-04-14 09:15:19] j...@php.net

Also, the possible fix to prevent this in PHP should consider all the
plural gettext functions:

ngettext(), dngettext() and dcngettext()




[2009-04-14 09:13:27] j...@php.net

"In the "C" locale, or if none of the used catalogs contain a
translation for msgid, the ngettext, dngettext and dcngettext functions
return msgid if n == 1, or msgid_plural if n != 1."

That crash should be reported to Sun too so they can fix their gettext
implementation. :)



[2009-03-15 15:07:08] d...@php.net

Description:

Passing -1 to the count argument of dcngettext leads to a PHP core dump

on OpenSolaris.






Reproduce code:
---
make test TESTS=ext/gettext/tests

will crash when testing dcngettext.phpt

Expected result:

no crash

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0xfedaaa76 in _real_gettext_u () from /lib/libc.so.1
(gdb) bt
#0  0xfedaaa76 in _real_gettext_u () from /lib/libc.so.1
#1  0xfeda8d7a in dcngettext () from /lib/libc.so.1
#2  0x080f8692 in zif_dcngettext (ht=5, return_value=0x83d4b0c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
    at /export/home/dsp/dev/c/php52/ext/gettext/gettext.c:356
#3  0x08275389 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x8047320) at zend_vm_execute.h:200
#4  0x08274b39 in execute (op_array=0x83d5090) at zend_vm_execute.h:92
#5  0x0825b469 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /export/home/dsp/dev/c/php52/Zend/zend.c:1134
#6  0x08223079 in php_execute_script (primary_file=0x8047a94) at 
/export/home/dsp/dev/c/php52/main/main.c:2023
#7  0x082d7a09 in main (argc=2, argv=0x8047b18) at 
/export/home/dsp/dev/c/php52/sapi/cli/php_cli.c:1133









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

#47365 [Opn->Fbk]: ip2long: 32bis vs. 64bit!

[dsp]

 ID:   47365
 Updated by:   d...@php.net
 Reported By:  flobee at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: *Network Functions
 Operating System: SunOS
 PHP Version:  5.2.9RC1
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Which Solaris Version. Solaris 10. On Sparc or on x86?

On OpenSolaris x86 64 bit it returns false as expected:

~/> php -r "var_dump(ip2long('web.de'));"  
   
bool(false)
~/> isainfo -b 
   
64
~/> uname -a   
   
SunOS Stanford 5.11 snv_106 i86pc i386 i86pc Solaris
~/> php -v 
   
PHP 5.2.6 (cli) (built: Jan 28 2009 01:43:42) (DEBUG)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies



Previous Comments:


[2009-02-12 09:27:18] flobee at gmail dot com

Description:

ip2long seems to be buggy on 64 Bit Solaris:
Tested with: php5.2.2, php5.2.8



Reproduce code:
---
64bit Solaris
#php -r "echo 'x:' . ip2long('web.de') .\"\n\";"
// x:4294967295

32bit Solaris
#php -r "echo 'x:' . ip2long('web.de') .\"\n\";"
// x:false







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

#47149 [Asn->Csd]: Recent CGI patches completely break functionality with Apache

[dsp]

 ID:   47149
 Updated by:   d...@php.net
 Reported By:  daniel dot gorski at develnet dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.3.0alpha3
 Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2009-01-19 12:59:36] j...@php.net

David, you break, you fix. ;)



[2009-01-19 12:36:44] daniel dot gorski at develnet dot org

Description:

The recent patch in sapi/cgi/cgi_main.c breaks the functionality with
Apache.

This is the culprit: <http://news.php.net/php.cvs/55503>

- if (env_path_translated != NULL && env_redirect_url != NULL) {
+ if (env_path_translated != NULL && env_redirect_url != NULL &&
+ orig_script_filename != NULL && script_path_translated != NULL
&&
+ strcmp(orig_script_filename, script_path_translated) != 0) {

The result is, that Apache tries to *parse* the CGI binary as it would
be a PHP file. Requests to this CGI emit following:

Warning: Unexpected character in input: '' (ASCII=15) state=0 in
/mnt/dev/php-bin/cgi on line 356
Warning: Unexpected character in input: '' (ASCII=2) state=0 in
/mnt/dev/php-bin/cgi on line 356 Warning: Unexpected character in input:
' in /mnt/dev/php-bin/cgi on line 356
Warning: Unexpected character in input: ' in /mnt/dev/php-bin/cgi on
line 356 Parse error: syntax error, unexpected T_STRING in
/mnt/dev/php-bin/cgi on line 356 

... where /mnt/dev/php-bin/cgi is the PHP CGI binary.

This used to work before the patch in question and works again if I
revert this patch.

The CGI configuration settings in my httpd.conf are staight forward:

  ScriptAlias /php-bin "/home/goosh/dev/php-bin"
  
  AllowOverride All
  Options All
  Order allow,deny
  Allow from all
  
  
  AddHandler   php5-script .php .html
  Action   php5-script /php-bin/cgi
  

My Apache httpd version is Apache/2.2.8

regards dtg

Reproduce code:
---
-

Expected result:

Working PHP via the CG interface.

Actual result:
--
Trash, CGI not working.





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

#47042 [Opn->Csd]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache

[dsp]

 ID:   47042
 Updated by:   d...@php.net
 Reported By:  sriram dot natarajan at sun dot com
-Status:   Open
+Status:   Closed
 Bug Type: CGI related
 Operating System: linux , solaris
 PHP Version:  5.2.8
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2009-01-08 22:19:12] sriram dot natarajan at sun dot com

previous patch had whitespaces instead of tabs causing the patch to
appear distorted. 

posting a same patch with this issue addressed
--- sapi/cgi/cgi_main.c.ORIGThu Jan  8 14:18:25 2009
+++ sapi/cgi/cgi_main.c Thu Jan  8 14:18:31 2009
@@ -960,7 +960,9 @@
TRANSLATE_SLASHES(env_document_root);
}
 
-   if (env_path_translated != NULL &&
env_redirect_url != NULL) {
+   if (env_path_translated != NULL &&
env_redirect_url != NULL && 
+   orig_script_filename != NULL &&
script_path_translated != NULL &&
+   strcmp(orig_script_filename,
script_path_translated) != 0) {
/* 
   pretty much apache specific.  If we
have a redirect_url
   then our script_filename and
script_name point to the



[2009-01-08 20:06:25] sriram dot natarajan at sun dot com

here is the suggested patch to address this issue

--- sapi/cgi/cgi_main.c.ORIGWed Jan  7 07:10:14 2009
+++ sapi/cgi/cgi_main.c Wed Jan  7 19:37:21 2009
@@ -960,16 +960,18 @@
TRANSLATE_SLASHES(env_document_root);
}
 
-   if (env_path_translated != NULL &&
env_redirect_url != NULL) {
-   /* 
-  pretty much apache specific.  If we
have a redirect_url
-  then our script_filename and
script_name point to the
-  php executable
-   */
-   script_path_translated =
env_path_translated;
-   /* we correct SCRIPT_NAME now in case
we don't have PATH_INFO */
-   env_script_name = env_redirect_url;
-   }
+if (env_path_translated != NULL &&
env_redirect_url != NULL &&
+orig_script_filename != NULL &&
script_path_translated != NULL &&
+strcmp(orig_script_filename,
script_path_translated) != 0) {
+/*
+   pretty much apache specific.  If we
have a redirect_url
+   then our script_filename and
script_name point to the
+   php executable
+*/
+script_path_translated =
env_path_translated;
+/* we correct SCRIPT_NAME now in case
we don't have PATH_INFO */
+env_script_name = env_redirect_url;
+}



[2009-01-08 20:04:39] sriram dot natarajan at sun dot com

Description:

currently, php cgi sapi code checks for redirect url and
env_path_translated to determine if the request is coming from apache
web server and accordingly modifies the CGI environment variables so
that server can continue processing. 

however, this check is insufficient considering that any web server
exporting SCRIPT_FILENAME and REDIRECT_URL with some value will be hit
by the apache specific processing.



Reproduce code:
---
  if (env_path_translated != NULL && env_redirect_url != NULL)
{
/*
   pretty much apache specific.  If we have a
redirect_url
   then our script_filename and script_name point to
the
   php executable
*/
script_path_translated = env_path_translated;
/* we correct SCRIPT_NAME now in case we don't have
PATH_INFO */
env_script_name = env_redirect_url;
}



Expected result:

server should continue processing

Actual result:
--
no input file is returned





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

#46938 [Opn->Bgs]: Make getopt() report wrong options

[dsp]

 ID:   46938
 Updated by:   d...@php.net
 Reported By:  kristof dot coomans at telenet dot be
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Irrelevant
 PHP Version:  5.3CVS-2008-12-24 (snap)
 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

Expected behavior.


Previous Comments:


[2008-12-24 10:13:45] kristof dot coomans at telenet dot be

Description:

Now that PHP 5.3 will have getopt() available on all platforms, I
think
it's important to also make it as usable as possible.

Currently, getopt() does not report in any way if there were any wrong
options provided on the command line. It would be nice to be able to
give the end user feedback on non-existing options he/she provided, or
about options he/she provided that require a value but for which no
value was supplied.

The ability to retrieve a list of option errors should be provided,
either by:
- throwing an exception
or
- a 3rd by-reference array argument to getopt()






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

#46937 [NoF->Bgs]: Make getopt() usable with non-option arguments

[dsp]

 ID:   46937
 Updated by:   d...@php.net
 Reported By:  kristof dot coomans at telenet dot be
-Status:   No Feedback
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Doesn't matter
 PHP Version:  5.3CVS-2008-12-24 (snap)
 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

Expected behavior.


Previous Comments:


[2009-01-02 12:54:58] d...@php.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.





[2008-12-24 10:03:30] kristof dot coomans at telenet dot be

Description:

Now that PHP 5.3 will have getopt() available on all platforms, I think
it's important to also make it as usable as possible.

Currently, getopt() is not usable for command line scripts that have
both option and non-option arguments, because it doesn't modify argv, as
pointed out already in 2003 in this comment:
http://www.php.net/getopt#34163. Stripping away the option arguments
from argv when a call to getopt() is made would be a great improvement.
User land code can handle the remaining non-option arguments from argv
then.






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

#46937 [Opn->NoF]: Make getopt() usable with non-option arguments

[dsp]

 ID:   46937
 Updated by:   d...@php.net
 Reported By:  kristof dot coomans at telenet dot be
-Status:   Open
+Status:   No Feedback
 Bug Type: Feature/Change Request
 Operating System: Doesn't matter
 PHP Version:  5.3CVS-2008-12-24 (snap)
 New Comment:

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.




Previous Comments:


[2008-12-24 10:03:30] kristof dot coomans at telenet dot be

Description:

Now that PHP 5.3 will have getopt() available on all platforms, I think
it's important to also make it as usable as possible.

Currently, getopt() is not usable for command line scripts that have
both option and non-option arguments, because it doesn't modify argv, as
pointed out already in 2003 in this comment:
http://www.php.net/getopt#34163. Stripping away the option arguments
from argv when a call to getopt() is made would be a great improvement.
User land code can handle the remaining non-option arguments from argv
then.






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

#46636 [Asn->Fbk]: feof() blocking on non-blocking socket

[dsp]

 ID:   46636
 Updated by:   [EMAIL PROTECTED]
 Reported By:  aragon at phat dot za dot net
-Status:   Assigned
+Status:   Feedback
 Bug Type: Streams related
 Operating System: FreeBSD 7.0-STABLE
 PHP Version:  5.2.7RC4
 Assigned To:  dsp
 New Comment:

Please try using this CVS snapshot:

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

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




Previous Comments:


[2008-11-22 10:39:18] [EMAIL PROTECTED]

David, please check when checking #46049



[2008-11-21 13:31:18] [EMAIL PROTECTED]

I will, but it seems related to this one:
http://bugs.php.net/bug.php?id=46049



[2008-11-21 08:30:29] [EMAIL PROTECTED]

Arnaud, can you take a look please?

http://tinyurl.com/6g42xf



[2008-11-21 02:59:04] aragon at phat dot za dot net

Sorry, I pasted misleading reproduce code.  It should be:

 0) {
echo $i.':'.(time()-$start).chr(10);
if (feof($socket)) break;
echo $i++.':'.(time()-$start).chr(10);
switch ($state) {
case 1:
fwrite($socket, 'GET /blog HTTP/1.0' .
chr(13).chr(10).chr(13).chr(10));
$state = 2; break;
case 2:
if (fread($socket, 8192)) echo 'ooo'.chr(10); break;
}
}
}
echo (time()-$start).chr(10);
?>



[2008-11-21 02:56:54] aragon at phat dot za dot net

Description:

There was a change since 5.2.6 release that is causing feof() to block
when testing a non-blocking socket for EOF.  It happens if the socket
has no data waiting in its buffer and is open.

If I compare 5.2.6 and 5.2.7 code it looks like
main/streams/streams.c:642:

if (!stream->eof && PHP_STREAM_OPTION_RETURN_ERR ==
php_stream_set_option(stream,
PHP_STREAM_OPTION_CHECK_LIVENESS,
-1, NULL)) {
stream->eof = 1;
}

In 5.2.6 php_stream_set_option is called with a value of 0, not -1.

Reproduce code:
---
 0) {
echo $i.':'.time().chr(10);
if (feof($socket)) break;
echo $i++.':'.time().chr(10);
switch ($state) {
case 1:
fwrite($socket, 'GET /blog HTTP/1.0' .
chr(13).chr(10).chr(13).chr(10));
$state = 2; break;
case 2:
if (fread($socket, 8192)) echo 'ooo'.chr(10); break;
}
}
}
echo time().chr(10);
?>

Expected result:

1:0
1:0
1:0
2:0
2:0
2:0
ooo
3:0
3:0
0


Actual result:
--
1:0
1:0
1:5
2:5
2:5
2:5
ooo
3:5
3:5
5






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

#46049 [Fbk->Csd]: feof() hangs

[dsp]

 ID:   46049
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Streams related
 Operating System: Linux
 PHP Version:  5.3CVS-2008-09-11 (CVS)
 Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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

Patch was reverted


Previous Comments:


[2008-11-24 02:19:44] [EMAIL PROTECTED]

If everybody is fine with that, I will revert the patch.



[2008-11-21 17:46:28] [EMAIL PROTECTED]


Shorter reproduce code:



The feof() will block until timeout is reached.

David, your fix correctly made feof() behave as documented (blocks
until timeout is reached if no data is available), but should feof()
really blocks here ? It seems it never behaved as documented (checked
php4.4, 5.1, 5.2.6).



[2008-11-18 23:46:15] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

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





[2008-11-05 13:43:24] [EMAIL PROTECTED]

Jani: I think it's an issue with the ssl socks, as my patch didn't
patch 
those. I try to have time to have a look on this, but I 
cannot reproduce the patch yet even though I sit down with sebstian and

try to figure out what's going wrong.



[2008-10-28 22:08:32] [EMAIL PROTECTED]

David, I guess we just have to revert that bad patch of yours then?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46049

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

#43782 [Csd->Tbd]: feof() does not detect timeout on socket

[dsp]

 ID:   43782
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ml at foofree dot sk
-Status:   Closed
+Status:   To be documented
 Bug Type: Streams related
 Operating System: *
 PHP Version:  5.2,5.3CVS (2008-07-15)
 Assigned To:  dsp
 New Comment:

The patch was reverted as it caused problems. We might want to edit the
documentation instead.


Previous Comments:


[2008-08-26 16:06:45] [EMAIL PROTECTED]

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.





[2008-01-08 01:19:23] ml at foofree dot sk

Description:

>From docs:

"Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE."

...

"If a connection opened by fsockopen() wasn't closed by the server,
feof() will wait until a timeout has been reached to return TRUE. The
default timeout value is 60 seconds. You may use stream_set_timeout() to
change this value."



feof() dows not wait and returns TRUE instead of FALSE if timeout
reached (server does not closed connection and there is no data in
timeout time slot).

* server does not closed connection,
* timeout wa reached

Reproduce code:
---
$s = stream_socket_client('tcp://www.php.net:80', $errno, $errstr, 10,
STREAM_CLIENT_CONNECT);

stream_set_timeout($s, 4);

$response = '';
while (feof($s) !== TRUE) {

   if (($foo = @fread($s, 1024 * 8)) === FALSE) return NULL;
   $response = $response . $foo;
};

print "OK";

Expected result:

prints "OK" approx. in 4 seconds

Actual result:
--
hangs forever





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

#46049 [Fbk]: feof() hangs

[dsp]

 ID:   46049
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Streams related
 Operating System: Linux
 PHP Version:  5.3CVS-2008-09-11 (CVS)
 Assigned To:  dsp
 New Comment:

If everybody is fine with that, I will revert the patch.


Previous Comments:


[2008-11-21 17:46:28] [EMAIL PROTECTED]


Shorter reproduce code:



The feof() will block until timeout is reached.

David, your fix correctly made feof() behave as documented (blocks
until timeout is reached if no data is available), but should feof()
really blocks here ? It seems it never behaved as documented (checked
php4.4, 5.1, 5.2.6).



[2008-11-18 23:46:15] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

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





[2008-11-05 13:43:24] [EMAIL PROTECTED]

Jani: I think it's an issue with the ssl socks, as my patch didn't
patch 
those. I try to have time to have a look on this, but I 
cannot reproduce the patch yet even though I sit down with sebstian and

try to figure out what's going wrong.



[2008-10-28 22:08:32] [EMAIL PROTECTED]

David, I guess we just have to revert that bad patch of yours then?



[2008-09-11 12:17:57] [EMAIL PROTECTED]

David, it appears that this problem is caused by this patch of yours:
http://news.php.net/php.cvs/52689
Take a look at it please.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46049

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

#46595 [Opn->Csd]: Use cc as default compiler

[dsp]

 ID:   46595
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Unix
 PHP Version:  5.3.0alpha2
 Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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


Previous Comments:


[2008-11-17 15:01:31] [EMAIL PROTECTED]

Description:

Use the cc binary as a default compiler. The AC_PROG_CC macro usually 
checks for GCC first. There are good reasons to not use gcc and install

another default compiler as the cc binary. Therefore AC_PROG_CC should

use cc and then fallback to gcc.






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

#46512 [Asn->Fbk]: fsockopen() timeout can't be below 1.0 with SSL

[dsp]

 ID:   46512
 Updated by:   [EMAIL PROTECTED]
 Reported By:  noah at rave dot ca
-Status:   Assigned
+Status:   Feedback
 Bug Type: OpenSSL related
 Operating System: Windows Server 2003
 PHP Version:  5.2.7RC2
 Assigned To:  dsp
 New Comment:

In which version did it work for you. For me it seems to be the same
behaviour as in PHP 5.2.6. I tested it on Linux.


Previous Comments:


[2008-11-06 20:40:00] noah at rave dot ca

I'm actually using RC3, which is not in the list...



[2008-11-06 20:35:24] noah at rave dot ca

Description:

When you use fsockopen and connect to SSL if the timeout is less then
1.0 it will cause an error... If it's 1.0 or over it will work as
expected...

Reproduce code:
---
if ($fp = fsockopen('ssl://www.website.com', 443, $errno, $errstr,
0.1))
{
$out = "GET /schedule/schedule_end/ HTTP/1.1\r\n";
$out .= "Host: www.website.com\r\n";
$out .= "Connection: Close\r\n\r\n";
fputs($fp, $out);
fclose($fp);
}

SHOWS ERROR:

Warning: fsockopen() [function.fsockopen]: SSL: connection timeout in
C:\Websites\website.com\website\include\show\admin\a.php on line 2

Warning: fsockopen() [function.fsockopen]: Failed to enable crypto in
C:\Websites\website.com\website\include\show\admin\a.php on line 2

Warning: fsockopen() [function.fsockopen]: unable to connect to
ssl://www.website.com:443 (Unknown error) in
C:\Websites\website.com\website\include\show\admin\a.php on line 2




if ($fp = fsockopen('ssl://www.website.com', 443, $errno, $errstr,
1))
{
$out = "GET /schedule/schedule_end/ HTTP/1.1\r\n";
$out .= "Host: www.website.com\r\n";
$out .= "Connection: Close\r\n\r\n";
fputs($fp, $out);
fclose($fp);
}

WORKS AS EXPECTED!!!

Expected result:

It should run with a 0.05, 0.1 or 0.99 timeout as it did in previous
versions...






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

#46513 [Opn->Csd]: Missing compiler flags for suncc

[dsp]

 ID:   46513
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Solaris
 PHP Version:  5.3.0alpha2
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2008-11-06 21:53:33] [EMAIL PROTECTED]

Description:

At the moment the php buildsystem does not use any suncc specific
compiler flags if someone tries to compile with the suncc.
Please add suncc specific compiler flags to the buildsystem if the
suncc compiler is detected. The default compiler flags for the gcc are
not compatible with suncc and therefore will result in errors. A useful
list might be -fsimple=2 -xnorunpath -xO4 -xalias_level=basic -xipo=1
-xlibmopt -xprefetch_level=1 -xprefetch=auto -xstrconst -xtarget=native
-zlazyload. It will use floating point (fsimple) and math lib
optimization (libmopt) and try to optimize across object files. It also
generates processor specific code (xtarget=native) and tries to
eleminate duplicated strings (xstrconst). In addition it does
optimization based on basic assumptions about used c types
(xalias_level=basic). The -xO4 optimization flags should generate useful
and fast code without breaking stuff (which might happen if you use
-xO5).






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

#46049 [Asn]: feof() hangs

[dsp]

 ID:   46049
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Streams related
 Operating System: Linux
 PHP Version:  5.3CVS-2008-09-11 (CVS)
 Assigned To:  dsp
 New Comment:

Jani: I think it's an issue with the ssl socks, as my patch didn't
patch 
those. I try to have time to have a look on this, but I 
cannot reproduce the patch yet even though I sit down with sebstian and

try to figure out what's going wrong.


Previous Comments:


[2008-10-28 22:08:32] [EMAIL PROTECTED]

David, I guess we just have to revert that bad patch of yours then?



[2008-09-11 12:17:57] [EMAIL PROTECTED]

David, it appears that this problem is caused by this patch of yours:
http://news.php.net/php.cvs/52689
Take a look at it please.



[2008-09-11 12:13:58] [EMAIL PROTECTED]

Description:

The code below works fine with PHP 5.2.6 (and earlier), but not with
the unreleased PHP 5.2.7 and PHP 5.3.0:

892 $handle = @fopen($url, 'r');
893
894 if (!$handle) {
895 throw new RuntimeException(
896   'Could not connect to the Selenium RC server.'
897 );
898 }
899
900 stream_set_blocking($handle, 1);
901 stream_set_timeout($handle, 0, $this->timeout);
902
903 $info = stream_get_meta_data($handle);
904 $response = '';
905
906 while ((!feof($handle)) && (!$info['timed_out'])) {
907 $response .= fgets($handle, 4096);
908 $info = stream_get_meta_data($handle);
909 }
910
911 fclose($handle);

The code above hangs with PHP 5.2.7 and PHP 5.3.0 in line 906 as shown
using Xdebug's tracing:

fopen() Driver.php:892
stream_set_blocking() Driver.php:900
stream_set_timeout() Driver.php:901
stream_get_meta_data() Driver.php:903
feof() Driver.php:906
fgets() Driver.php:907
stream_get_meta_data() Driver.php:908
feof() Driver.php:906

The second feof() call above hangs.

More information can be found here:

  - http://static.phpunit.de/trace.818532121.xt
  - http://static.phpunit.de/strace.txt

Changing the loop to

while (!$info['eof'] && !$info['timed_out']) {
$response .= fgets($handle, 4096);
$info = stream_get_meta_data($handle);
}

fixes the problem. This means a difference between feof() and
$info['eof'].






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

#46016 [Opn->Bgs]: display_errors = Off doesn't work

[dsp]

 ID:   46016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at jamesvalero dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows 2003 R2 STD
 PHP Version:  5.2.6
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.




Previous Comments:


[2008-09-07 09:43:10] php at jamesvalero dot com

Correction: Calling the linked report "closed" may have been
misleading. A better way of asking should have been: Are reports tagged
with "No Feedback" still looked at when new comments are submitted by
other members of the community?



[2008-09-07 09:34:48] php at jamesvalero dot com

http://bugs.php.net/bug.php?id=44729 is the report in question. Is this
the same submission you were referring to?



[2008-09-07 09:32:28] php at jamesvalero dot com

I replied in another similar bug report but it looked like it was
already closed. Does replying in closed bugs, where I am not the owner,
re-open stale bug reports?

Thanks



[2008-09-07 09:30:07] php at jamesvalero dot com

note on the differences in the domain name: I forgot to edit the name
in the error output. Is it possible to modify the original post?



[2008-09-07 09:28:49] [EMAIL PROTECTED]

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46016

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

#43782 [Opn->Csd]: feof() does not detect timeout on socket

[dsp]

 ID:   43782
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ml at foofree dot sk
-Status:   Open
+Status:   Closed
 Bug Type: Streams related
 Operating System: *
 PHP Version:  5.2,5.3CVS (2008-07-15)
-Assigned To:  
+Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2008-01-08 01:19:23] ml at foofree dot sk

Description:

>From docs:

"Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE."

...

"If a connection opened by fsockopen() wasn't closed by the server,
feof() will wait until a timeout has been reached to return TRUE. The
default timeout value is 60 seconds. You may use stream_set_timeout() to
change this value."



feof() dows not wait and returns TRUE instead of FALSE if timeout
reached (server does not closed connection and there is no data in
timeout time slot).

* server does not closed connection,
* timeout wa reached

Reproduce code:
---
$s = stream_socket_client('tcp://www.php.net:80', $errno, $errstr, 10,
STREAM_CLIENT_CONNECT);

stream_set_timeout($s, 4);

$response = '';
while (feof($s) !== TRUE) {

   if (($foo = @fread($s, 1024 * 8)) === FALSE) return NULL;
   $response = $response . $foo;
};

print "OK";

Expected result:

prints "OK" approx. in 4 seconds

Actual result:
--
hangs forever





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

#44487 [Asn->Csd]: call_user_method_array issues a warning when throwing an exception

[dsp]

 ID:   44487
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.2.6RC2
 Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2008-03-20 00:22:15] [EMAIL PROTECTED]

Description:

call_user_method_array issues a "cannot call method foo()" warning when
 an exception is thrown.


Reproduce code:
---
class Foo
{
public function bar()
{
throw new Exception();
}

public function test()
{
call_user_func_array(array($this, 'bar'), array());
}
}

try {
$bar = new Foo();
call_user_method_array('test', $bar, array()) ;

} catch (Exception $e) {
}


Expected result:

no output

Actual result:
--
Warning: call_user_method_array(): Unable to call test() in
/path/to/call.php on line 17






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

#44487 [Opn->Asn]: call_user_method_array issues a warning when throwing an exception

[dsp]

 ID:   44487
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.2.6RC2
-Assigned To:  
+Assigned To:  dsp


Previous Comments:


[2008-03-20 00:22:15] [EMAIL PROTECTED]

Description:

call_user_method_array issues a "cannot call method foo()" warning when
 an exception is thrown.


Reproduce code:
---
class Foo
{
public function bar()
{
throw new Exception();
}

public function test()
{
call_user_func_array(array($this, 'bar'), array());
}
}

try {
$bar = new Foo();
call_user_method_array('test', $bar, array()) ;

} catch (Exception $e) {
}


Expected result:

no output

Actual result:
--
Warning: call_user_method_array(): Unable to call test() in
/path/to/call.php on line 17






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

#43167 [Asn]: ReflectionMethod::isConstructor() does not work for interfaces

[dsp]

 ID:   43167
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5.2.*
 Assigned To:  johannes
 New Comment:

In my opinion thats not a bug. An interface has no constructor as it
cannot be initialized. As helly said, it simple forces the protocol for
the constructor.


Previous Comments:


[2007-11-06 13:25:23] [EMAIL PROTECTED]

This is discussable as it is not really a constructor here. It simply
forces the protocol for the constructor. We do mark abstract
constructors as ctors though, so we imho should do so in interfaces as
well.
[EMAIL PROTECTED] PHP_5_3]$ php -r 'abstract class t{abstract function
__construct();} ReflectionClass::export("T");'
make: `sapi/cli/php' is up to date.
Class [  abstract class t ] {
  @@ Command line code 1-1

  - Constants [0] {
  }

  - Static properties [0] {
  }

  - Static methods [0] {
  }

  - Properties [0] {
  }

  - Methods [1] {
Method [  abstract public method __construct ] {
  @@ Command line code 1 - 1
}
  }
}



[2007-11-01 07:52:22] [EMAIL PROTECTED]

Description:

ReflectionMethod::isConstructor() does not work for methods that are
named __construct() in interfaces.

Reproduce code:
---
getMethod('__construct');
var_dump($constructor->isConstructor());

Expected result:

bool(true)

Actual result:
--
bool(false)





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

#43761 [Opn->Bgs]: fatal error: undefined functions: bcadd(), bcsub()

[dsp]

 ID:   43761
 Updated by:   [EMAIL PROTECTED]
 Reported By:  george dot girtsou at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: BC math related
 Operating System: Linux
 PHP Version:  5.2.5
 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

Please compile PHP with --enable-bcmath (and do a make distclean
before, if needed). BCmath is disabled by default (See Installation
section in the bcmath php.net manual pages)


Previous Comments:


[2008-01-05 20:12:24] george dot girtsou at gmail dot com

Just found that the problem is with both bcadd() and bcsub() functions.



[2008-01-05 19:49:15] george dot girtsou at gmail dot com

Description:

I get an undefined bcadd() function error on PHP 5.2.5.

"Fatal error: Call to undefined function bcadd() in  on line
"

On manual http://php.net/bcadd it says bcadd() function is supported in
PHP 4 and PHP 5.

Thank you.






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

#43729 [Opn->Bgs]: Fread isnt able to read

[dsp]

 ID:   43729
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rc at opelgt dot org
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Mac OS 10.4.11
 PHP Version:  4.4.7
 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

Sorry, but this is expected behaviour. filesize caches the size (in
that case 4). You write to byte 5 and 6 when doing fwrite($dh, $str2)
bust just read bye 0 to 4 when doing the last fread before cleaning the
cache.


Previous Comments:


[2008-01-02 11:22:16] rc at opelgt dot org

Description:

Although the pointer is at position 0 and filesize is cached with the 
value of 4 fread reads nothing.

A clearstatcache is necessary for fread to operate correct.

Reproduce code:
---
\n";
echo 'pointer after write at: '.ftell($dh).'';
ftruncate($dh, '0');
echo 'pointer after truncate at: '.ftell($dh).'';
echo 'filesize after truncate is: '.filesize($datei).'';
fwrite($dh, $str2);
echo 'pointer after second write at: '.ftell($dh).'';
rewind($dh);
echo 'pointer after rewind at: '.ftell($dh).'';
echo 'content: '.fread($dh, filesize($datei)).'';
clearstatcache();
echo 'content: '.fread($dh, filesize($datei));
fclose($dh);
?>

Expected result:

content: 1234
pointer after write at: 4
pointer after truncate at: 4
filesize after truncate is: 4
pointer after second write at: 6
pointer after rewind at: 0
content: 56
content: 56

Actual result:
--
content: 1234
pointer after write at: 4
pointer after truncate at: 4
filesize after truncate is: 4
pointer after second write at: 6
pointer after rewind at: 0
content: 
content: 56





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

#43663 [Asn->Csd]: Extending PDO class with a __call() function doesn't work

[dsp]

 ID:   43663
 Updated by:   [EMAIL PROTECTED]
 Reported By:  anthony dot parsons at manx dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: PDO related
 Operating System: Linux 2.6.23 (Gentoo)
 PHP Version:  5.2.5
-Assigned To:  
+Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2007-12-23 23:08:00] anthony dot parsons at manx dot net

Description:

With a user-defined class that extends PDO, a __call() method does 
nothing at all. The class behaves as if it didn't exist.

I've tested it on a few other internal classes (the xml-related 
ones) where it works fine, and also with all but the PDO extension 
disabled with the same result.


Reproduce code:
---
';
}
function foo() {
echo "Called foo in ".__CLASS__.'';
}
}
$a = new test('sqlite::memory:');
$a->foo();
$a->bar();
?>

Expected result:

"Called foo in test
Called bar in test"

Actual result:
--
"Called foo in test

 Fatal error: Call to undefined method test::bar() in call.php on 
line 24"





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

#43663 [Opn->Asn]: Extending PDO class with a __call() function doesn't work

[dsp]

 ID:   43663
 Updated by:   [EMAIL PROTECTED]
 Reported By:  anthony dot parsons at manx dot net
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Linux 2.6.23 (Gentoo)
 PHP Version:  5.2.5


Previous Comments:


[2007-12-23 23:08:00] anthony dot parsons at manx dot net

Description:

With a user-defined class that extends PDO, a __call() method does 
nothing at all. The class behaves as if it didn't exist.

I've tested it on a few other internal classes (the xml-related 
ones) where it works fine, and also with all but the PDO extension 
disabled with the same result.


Reproduce code:
---
';
}
function foo() {
echo "Called foo in ".__CLASS__.'';
}
}
$a = new test('sqlite::memory:');
$a->foo();
$a->bar();
?>

Expected result:

"Called foo in test
Called bar in test"

Actual result:
--
"Called foo in test

 Fatal error: Call to undefined method test::bar() in call.php on 
line 24"





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

#30380 [Asn->Csd]: getopt_long doesn't work unless HARTMUT_0 is defined

[dsp]

 ID:   30380
 Updated by:   [EMAIL PROTECTED]
 Reported By:  per at computer dot org
-Status:   Assigned
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: linux 2.4.27
 PHP Version:  4.3.9
 Assigned To:  hholzgra
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2007-10-03 10:20:50] [EMAIL PROTECTED]

getopt with longopts work on every platform in php 5.3



[2004-11-27 20:08:33] per at computer dot org

Also applies to 4.3.10RC1.



[2004-10-11 14:15:43] per at computer dot org

Just a quick comment - as far as I can tell using getopt() with long
options works fine. Obviously I haven't exactly done exhaustive tests,
but still.



[2004-10-11 11:08:28] [EMAIL PROTECTED]

ok, looks like bug #20063 was the reason for this ...



[2004-10-11 10:59:42] [EMAIL PROTECTED]

the commit message says

  getopt with long options reverted to configure problems
  (may find the wrong getopt.h so needed structures are not defined 
:( 
  )

have to dig through the archives to see what that really was about ...



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30380

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

#40501 [Opn->Csd]: fgetcsv can't handle trailing odd number of backslashes

[dsp]

 ID:   40501
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mike at opendns dot com
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Linux, debian sarge
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  dsp
 New Comment:

This bug has been fixed in CVS.

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

In PHP 5.3 there will be an additional escape character parameter.
Setting this parameter and the enclosure parameter to " will cause your
expected result.


Previous Comments:


[2007-04-18 09:29:05] frapa02 at hotmail dot com

Further thoughts on this...

The delimiter logic needs to be replaced according to the double quote
character rules (modified) in the above documentation (rfc4180.txt),
i.e. as follows:

*
7.  If double-quotes are used to enclose fields, then a double-quote
appearing inside a field must be escaped by preceding it with another
double quote.  For example:

   "aaa","b""bb","ccc"
*

However, fgetcsv needs to replace the above rule for double quote with
a test for the character supplied in the enclosure parameter. In other
words, the delimiter character is always the enclosure character itself,
but it can only delimit the same character.

Please email me if help is needed with analysis or testing.



[2007-04-18 09:00:16] frapa02 at hotmail dot com

I am experiencing this issue which is preventing me from processing
standard CSV file fields which have a backslash as the last character
before the double quote enclosure. e.g.

"field 1","field 2","field 3\",field 4"

This will result in fgetcsv only returning 3 fields instead of 4.

Perhaps the best way to fix this is to remove the test for
'escape_char' in the 'php_fgetcsv' function. If backward compatibility
is an issue, an additional parm to fgetcsv could be added to enable the
use of the escape character. It's default should be to use no escape
character.



[2007-02-15 20:11:54] mike at opendns dot com

Description:

If an element in a CSV file ends with an odd number of trailing
backslashes, it'll miss the enclosure character.

This isn't a documentation problem -
http://www.rfc-editor.org/rfc/rfc4180.txt
Backslashes are not escape characters in CSV.

This was part of bug #39538.  The other half of that bug was correctly
fixed.  This is still broken.

Reproduce code:
---
[EMAIL PROTECTED]:/tmp# cat -A csv.tmp
"this element contains the delimiter, and ends with an odd number of
backslashes (ex: 1)\",and it isn't the last element$

[EMAIL PROTECTED]:/tmp# cat test_csv.php


Expected result:

[EMAIL PROTECTED]:/tmp# php test_csv.php
array(2) {
  [0]=>
  string(88) "this element contains the delimiter, and ends with an odd
number of backslashes (ex: 1)\"
  [1]=>
  string(29) "and it isn't the last element"
}

Actual result:
--
[EMAIL PROTECTED]:/tmp# php test_csv.php
array(1) {
  [0]=>
  string(120) "this element contains the delimiter, and ends with an
odd number of backslashes (ex: 1)\",and it isn't the last element"
}





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

#30380 [Asn]: getopt_long doesn't work unless HARTMUT_0 is defined

[dsp]

 ID:   30380
 Updated by:   [EMAIL PROTECTED]
 Reported By:  per at computer dot org
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: linux 2.4.27
 PHP Version:  4.3.9
 Assigned To:  hholzgra
 New Comment:

getopt with longopts work on every platform in php 5.3


Previous Comments:


[2004-11-27 20:08:33] per at computer dot org

Also applies to 4.3.10RC1.



[2004-10-11 14:15:43] per at computer dot org

Just a quick comment - as far as I can tell using getopt() with long
options works fine. Obviously I haven't exactly done exhaustive tests,
but still.



[2004-10-11 11:08:28] [EMAIL PROTECTED]

ok, looks like bug #20063 was the reason for this ...



[2004-10-11 10:59:42] [EMAIL PROTECTED]

the commit message says

  getopt with long options reverted to configure problems
  (may find the wrong getopt.h so needed structures are not defined 
:( 
  )

have to dig through the archives to see what that really was about ...



[2004-10-11 07:58:41] [EMAIL PROTECTED]

Hartmut,

what was the reason why you disabled this again?

Derick



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30380

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

#35507 [Bgs]: feof does not report no-char on STDIN

[dsp at tdcspace dot dk]

 ID:   35507
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: win/nix
 PHP Version:  5.1.1
 New Comment:

hotddam - error
can't destroy the zero flag with "xor ax,ax" must use "mov ax,0" - sry

keyb_newchar_check proc far

mov  ax,1
int  16h   ; func=1
mov  ax,0
jz   nochar
inc  ax
nochar:
ret
keyb_newchar_check endp


Previous Comments:
----

[2005-12-01 22:08:58] dsp at tdcspace dot dk

This is what has been valid BIOS INT on the x86 family IBM compatible
since it came in early 80' !

---
TEST FOR KEY (SINGLE CHAR)
---
return: ax=0=no char waiting or ax=1=yes
 
keyb_newchar_check proc far

mov  ax,1
int  16h   ; func=1
xor  ax,ax
jz   nochar
inc  ax
nochar:
ret
keyb_newchar_check endp

-
GET WAITING KEY (SINGLE CHAR)
-
return: ax (AL) = char (if func key like F1 then its scan code)
note: if no waiting key - then the bios will wait for one

keyb_newchar_get proc far

xor  ax,ax
int  16h; func=0
or   al,al
jnz  noscan
mov  al,ah  ; scan code in ah
noscan:
xor  ah,ah
ret
keyb_newchar_get endp


SOURCE 

Public Domain/Freeware/Shareware by Ralf Brown: INTER60.ZIP X86 family
DOS/BIOS int's


B-1600---
INT 16 - KEYBOARD - GET KEYSTROKE
AH = 00h
Return: AH = BIOS scan code
AL = ASCII character
Notes:  on extended keyboards, this function discards any extended
keystrokes,
  returning only when a non-extended keystroke is available
the BIOS scan code is usually, but not always, the same as the
hardware
  scan code processed by INT 09.  It is the same for ASCII keystrokes
  and most unshifted special keys (F-keys, arrow keys, etc.), but
  differs for shifted special keys
some (older) clone BIOSes do not discard extended keystrokes and
manage
  function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
  keystrokes (same as with functions 10h and 20h), but will always
  translate prefix E0h to 00h. This allows old programs to use
extended
  keystrokes and should not cause compatibility problems
SeeAlso: AH=01h,AH=05h,AH=10h,AH=20h,AX=AF4Dh"K3PLUS",INT 18/AH=00h
SeeAlso: INT 09,INT 15/AH=4Fh
B-1601---
INT 16 - KEYBOARD - CHECK FOR KEYSTROKE
AH = 01h
Return: ZF set if no keystroke available
ZF clear if keystroke available
AH = BIOS scan code
AL = ASCII character
Note:   if a keystroke is present, it is not removed from the keyboard
buffer;
  however, any extended keystrokes which are not compatible with
83/84-
  key keyboards are removed by IBM and most fully-compatible BIOSes
in
  the process of checking whether a non-extended keystroke is
available
some (older) clone BIOSes do not discard extended keystrokes and
manage
  function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
  keystrokes (same as with functions 10h and 20h), but will always
  translate prefix E0h to 00h. This allows old programs to use
extended
  keystrokes and should not cause compatibility problems
SeeAlso: AH=00h,AH=11h,AH=21h,INT 18/AH=01h,INT 09,INT 15/AH=4Fh



[2005-12-01 20:30:13] [EMAIL PROTECTED]

I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.


--------

[2005-12-01 20:08:57] dsp at tdcspace dot dk

Tx for asking me !

In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.

In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself ! 


$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);

$handle = fopen('test', 'r'); // re-open
do {
  // start - EOF routine 
  $curpos = ftell($handle);
  fseek($handle, 0, SEEK_END);
  $endpos = ftell($handle);
  // test wether the current pos is the last pos (=eof)
  if ($endpos == $curpos) { echo " ..EOF"; break; }
  fseek($handle, $cur

#35507 [Bgs]: feof does not report no-char on STDIN

[dsp at tdcspace dot dk]

 ID:   35507
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: win/nix
 PHP Version:  5.1.1
 New Comment:

This is what has been valid BIOS INT on the x86 family IBM compatible
since it came in early 80' !

---
TEST FOR KEY (SINGLE CHAR)
---
return: ax=0=no char waiting or ax=1=yes
 
keyb_newchar_check proc far

mov  ax,1
int  16h   ; func=1
xor  ax,ax
jz   nochar
inc  ax
nochar:
ret
keyb_newchar_check endp

-
GET WAITING KEY (SINGLE CHAR)
-
return: ax (AL) = char (if func key like F1 then its scan code)
note: if no waiting key - then the bios will wait for one

keyb_newchar_get proc far

xor  ax,ax
int  16h; func=0
or   al,al
jnz  noscan
mov  al,ah  ; scan code in ah
noscan:
xor  ah,ah
ret
keyb_newchar_get endp


SOURCE 

Public Domain/Freeware/Shareware by Ralf Brown: INTER60.ZIP X86 family
DOS/BIOS int's


B-1600---
INT 16 - KEYBOARD - GET KEYSTROKE
AH = 00h
Return: AH = BIOS scan code
AL = ASCII character
Notes:  on extended keyboards, this function discards any extended
keystrokes,
  returning only when a non-extended keystroke is available
the BIOS scan code is usually, but not always, the same as the
hardware
  scan code processed by INT 09.  It is the same for ASCII keystrokes
  and most unshifted special keys (F-keys, arrow keys, etc.), but
  differs for shifted special keys
some (older) clone BIOSes do not discard extended keystrokes and
manage
  function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
  keystrokes (same as with functions 10h and 20h), but will always
  translate prefix E0h to 00h. This allows old programs to use
extended
  keystrokes and should not cause compatibility problems
SeeAlso: AH=01h,AH=05h,AH=10h,AH=20h,AX=AF4Dh"K3PLUS",INT 18/AH=00h
SeeAlso: INT 09,INT 15/AH=4Fh
B-1601---
INT 16 - KEYBOARD - CHECK FOR KEYSTROKE
AH = 01h
Return: ZF set if no keystroke available
ZF clear if keystroke available
AH = BIOS scan code
AL = ASCII character
Note:   if a keystroke is present, it is not removed from the keyboard
buffer;
  however, any extended keystrokes which are not compatible with
83/84-
  key keyboards are removed by IBM and most fully-compatible BIOSes
in
  the process of checking whether a non-extended keystroke is
available
some (older) clone BIOSes do not discard extended keystrokes and
manage
  function AH=00h and AH=10h the same
the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
  keystrokes (same as with functions 10h and 20h), but will always
  translate prefix E0h to 00h. This allows old programs to use
extended
  keystrokes and should not cause compatibility problems
SeeAlso: AH=00h,AH=11h,AH=21h,INT 18/AH=01h,INT 09,INT 15/AH=4Fh


Previous Comments:


[2005-12-01 20:30:13] [EMAIL PROTECTED]

I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.


----

[2005-12-01 20:08:57] dsp at tdcspace dot dk

Tx for asking me !

In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.

In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself ! 


$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);

$handle = fopen('test', 'r'); // re-open
do {
  // start - EOF routine 
  $curpos = ftell($handle);
  fseek($handle, 0, SEEK_END);
  $endpos = ftell($handle);
  // test wether the current pos is the last pos (=eof)
  if ($endpos == $curpos) { echo " ..EOF"; break; }
  fseek($handle, $curpos); // not EOF - return to last file pos 
  // end - EOF routine 

  echo "\r\nRead at " . $curpos;
  $buffer = fgets($handle, 9);
  }
while(true);
echo " ..END";
fclose($handle);



[2005-12-01 19:04:13] [EMAIL PROTECTED]

And how do you propose to distinguish "slow input" from "no 

#35507 [Fbk->Opn]: feof does not report no-char on STDIN

[dsp at tdcspace dot dk]

 ID:   35507
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: win/nix
 PHP Version:  5.1.1
 New Comment:

Tx for asking me !

In case of the keyboard input, the state is well defined from the bios
aka. the "waiting char status" of which all comp's have a (basic) BIOS
to report tat.

In case of a file (stream) it is possible to detect an EOF - (WITHOUT
having to read first) by using ftell()/fseek(). Ayway it may impose
some overhead. Nevertheless the code below will allways report EOF
without reading (ex. is with a zero len file). Try it urself ! 


$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);

$handle = fopen('test', 'r'); // re-open
do {
  // start - EOF routine 
  $curpos = ftell($handle);
  fseek($handle, 0, SEEK_END);
  $endpos = ftell($handle);
  // test wether the current pos is the last pos (=eof)
  if ($endpos == $curpos) { echo " ..EOF"; break; }
  fseek($handle, $curpos); // not EOF - return to last file pos 
  // end - EOF routine 

  echo "\r\nRead at " . $curpos;
  $buffer = fgets($handle, 9);
  }
while(true);
echo " ..END";
fclose($handle);


Previous Comments:


[2005-12-01 19:04:13] [EMAIL PROTECTED]

And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?



[2005-12-01 18:58:29] dsp at tdcspace dot dk

Better explain that the loop waits for a keyboard input
despite there is no input.



[2005-12-01 18:47:38] dsp at tdcspace dot dk

Description:

In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the 
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version

example: the loop should output etc

  do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
 }
  while(true);


THE PHP MANUAL SAYS -

feof (PHP 3, PHP 4, PHP 5)

feof -- Tests for end-of-file on a file pointer

Description

bool feof ( resource handle )

Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE. 
---

Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!








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

#35507 [Opn]: feof does not report no-char on STDIN

[dsp at tdcspace dot dk]

 ID:   35507
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: win/nix
 PHP Version:  5.1.1
 New Comment:

Better explain that the loop waits for a keyboard input
despite there is no input.


Previous Comments:


[2005-12-01 18:47:38] dsp at tdcspace dot dk

Description:

In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the 
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version

example: the loop should output etc

  do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
 }
  while(true);


THE PHP MANUAL SAYS -

feof (PHP 3, PHP 4, PHP 5)

feof -- Tests for end-of-file on a file pointer

Description

bool feof ( resource handle )

Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE. 
---

Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!








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

#35507 [NEW]: feof does not report no-char on STDIN

[dsp at tdcspace dot dk]

From: dsp at tdcspace dot dk
Operating system: win/nix
PHP version:  5.1.1
PHP Bug Type: Feature/Change Request
Bug description:  feof does not report no-char on STDIN

Description:

In a continous loop for processing data with options for
entering a process char (like 'q' for quit, etc.) - the 
feof() does not report no input (EOF) from STDIN (keyboard).
note: This is about the CLI version

example: the loop should output etc

  do {
if ( !feof(STDIN) ) { $x = fgetc(STDIN); echo $x; }
echo '.';
 }
  while(true);


THE PHP MANUAL SAYS -

feof (PHP 3, PHP 4, PHP 5)

feof -- Tests for end-of-file on a file pointer

Description

bool feof ( resource handle )

Returns TRUE if the file pointer is at EOF or an error occurs (including
socket timeout); otherwise returns FALSE. 
---

Apparantly "Tests for end-of-file on a file pointer" does
not TEST for anything !!




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

#35495 [Bgs]: feof() does not report EOF on a zero file

[dsp at tdcspace dot dk]

 ID:   35495
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: linux/win
 PHP Version:  5CVS, 4CVS (2005-11-30) (snap)
 Assigned To:  wez
 New Comment:

Taken from the PHP manual

feof -- Tests for end-of-file on a file pointer

Description

bool feof ( resource handle )

Returns TRUE if the file pointer is at EOF or an error occurs
(including socket timeout); otherwise returns FALSE. 


Read a file with only 4 chars "0123". The chars correspond to what
ftell() reports (0 at open) and 4 after reading 4 with fgets(5).

File-pointer is then 4 - aka the next read position which is beyond
last char and thus EOF. This must be proof enough of inconsistency.
Either the manual or the feof() need to be corrected - i prefer
feof().

Still php is great - and i help to make it better !


Previous Comments:


[2005-12-01 01:07:05] [EMAIL PROTECTED]

I get the same result with this C code:

#include 
#include 

int main() {
FILE *fd;
fd = fopen("/tmp/xxx", "r");
while (!feof(fd)) {
char buf[100];
fgets(buf, 100, fd); // remove that and you'll get endless
cycle
printf("read\n");
}
fclose(fd);
return 0;
}
(it reads once and stops just after that)
Doesn't look like a bug to me.
PHP behaves in the same way as the underlying OS.



[2005-11-30 23:43:40] [EMAIL PROTECTED]

Wez, sounds like something isn't working quite well in the streams
world?

----

[2005-11-30 22:46:26] dsp at tdcspace dot dk

what i don't understand is that the win/linux lower filesystem layer
maintains a filepointer of which it should be easy to detect/report a
EOF condition. The PHP handle as a file descriptor resource should
among things maintain this.

But i don't maintain php and thus don't know the reasons.

--------

[2005-11-30 22:40:21] dsp at tdcspace dot dk

nope - 5.1.2.2 cvs - same story - feof() still ignores a zero file



[2005-11-30 18:42:43] [EMAIL PROTECTED]

No, try the 5.1 snapshot.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35495

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

#35495 [Opn]: feof() does not report EOF on a zero file

[dsp at tdcspace dot dk]

 ID:   35495
 User updated by:  dsp at tdcspace dot dk
 Reported By:  dsp at tdcspace dot dk
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: linux/win
 PHP Version:  4.4.1
 New Comment:

what i don't understand is that the win/linux lower filesystem layer
maintains a filepointer of which it should be easy to detect/report a
EOF condition. The PHP handle as a file descriptor resource should
among things maintain this.

But i don't maintain php and thus don't know the reasons.


Previous Comments:


[2005-11-30 22:40:21] dsp at tdcspace dot dk

nope - 5.1.2.2 cvs - same story - feof() still ignores a zero file



[2005-11-30 18:42:43] [EMAIL PROTECTED]

No, try the 5.1 snapshot.



[2005-11-30 18:42:21] dsp at tdcspace dot dk

is there a cvs for 4.4.1



[2005-11-30 18:33:15] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-11-30 18:30:52] dsp at tdcspace dot dk

Description:

feof() does not report eof on a zero (0) length file

following code (similar to the ex. in the php manual) does
act like a new record was read - allthouh the file IS at eof.

$handle = @fopen("xxx", "r");
while (!feof($handle)) {
   $buffer = fgets($handle, 4096);
   echo $buffer;
   }
fclose($handle);







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