Bug #49382 [Com]: can't access DateTime->date

2013-07-09 Thread weirdan at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=49382&edit=1

 ID: 49382
 Comment by: weirdan at gmail dot com
 Reported by:klawd at kamundo dot de
 Summary:can't access DateTime->date
 Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   Debian GNU/Linux 5.0
 PHP Version:5.3.0
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

I'd say the bug is not that the property is not present before var_dump'ing 
object, but that the property is suddenly created. Unexpected side-effect.


Previous Comments:

[2013-07-09 11:29:41] hanskrentel at yahoo dot de

I wonder how this qualifies as a bug as any object can have variable properties 
and accessing undefined ones give notices.

Just sounds like standard PHP behavior here.


[2012-12-29 17:56:02] info at metashock dot net

I think it is interesting that the property can be accessed using reflection. 
Using the following example I can access the property:

$dt = new DateTime();
$o = new ReflectionObject($dt);
$p = $o->getProperty('date');
$date = $p->getValue($dt)); // returns the value of DateTime::$date

--------
[2010-08-04 22:36:58] weirdan at gmail dot com

if this was not intended to work this way, why won't you just fix it so that no 
properties are created as a result of print_r / Reflection::export() / 
foreach() / 
property_exist / array cast?


[2010-03-07 20:22:06] der...@php.net

->date being available is actually a side-effect of support for var_dump() 
here. I'll mark this as a feature request as it was not intended to work.


[2009-08-27 07:52:37] klawd at kamundo dot de

Description:

Can not access property date of DateTime.

Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;
gets me Notice: Undefined property: DateTime::$date

strangely though, this works:
$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt->date;
DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3 [timezone] 
=> UTC ) 1742-05-23 00:00:00








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

Bug #64882 [Fbk->Opn]: 'Could not open input file' error message goes to STDOUT

2013-05-23 Thread weirdan at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64882&edit=1

 ID: 64882
 User updated by:weirdan at gmail dot com
 Reported by:weirdan at gmail dot com
 Summary:'Could not open input file' error message goes to
 STDOUT
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Debian GNU/Linux
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Even though display_errors is set to STDOUT by default in php 5.3.25:

weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -i -n | grep 
display_errors
display_errors => STDOUT => STDOUT

(and display_startup_errors are off): 

weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -i -n | grep 
display_startup
display_startup_errors => Off => Off
weirdan@367-dsividov:~/Downloads$

the following 

weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n $(tempfile).php 
2>/dev/null
weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n $(tempfile).php
Could not open input file: /tmp/fileLHIKSE.php
weirdan@367-dsividov:~/Downloads$

clearly shows that startup errors are actually going to STDERR

But even I specify errors should go to STDERR, they go to STDOUT in php >= 
5.4.0:


weirdan@367-dsividov:~/Downloads$ for dir in `ls -d php-5* | grep -v tar`; do 
echo -n "$dir: "; $dir/sapi/cli/php -ddisplay_errors=STDERR -
ddisplay_startup_errors=0 -n $(tempfile).php 2>/dev/null; echo; done;

php-5.3.25:
php-5.4.0: Could not open input file: /tmp/filedhceXV.php

php-5.4.15: Could not open input file: /tmp/fileUv3FxW.php

php-5.4.7: Could not open input file: /tmp/fileBH6TsZ.php

weirdan@367-dsividov:~/Downloads$



to me it seems that startup errors started to go to STDOUT (regardless of 
display_errors and display_startup_errors value) in php-5.4.x and you can't 
really control it through either 
display_errors or display_startup_errors:

weirdan@367-dsividov:~/Downloads$ php-5.4.0/sapi/cli/php -
ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR -i | egrep 
'(display_errors|display_startup_errors|error_log)'
display_errors => STDERR => STDERR
display_startup_errors => Off => Off
error_log => no value => no value
weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -
ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR -i | egrep 
'(display_errors|display_startup_errors|error_log)'
display_errors => STDERR => STDERR
display_startup_errors => Off => Off
error_log => no value => no value
weirdan@367-dsividov:~/Downloads$ php-5.4.0/sapi/cli/php -n -
ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR $(tempfile).php 
2>/dev/null
Could not open input file: /tmp/file7laZhC.php
weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n -
ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR $(tempfile).php 
2>/dev/null
weirdan@367-dsividov:~/Downloads$


Previous Comments:

[2013-05-23 18:30:40] ahar...@php.net

This is controlled by the display_errors and error_log configuration variables: 
what do you get on each version if you run php -i | egrep 
'(display_errors|error_log)' ?

For example, I get:

adamh@swiftdesk7:/tmp$ php -i | egrep '(display_errors|error_log)'
display_errors => STDOUT => STDOUT
error_log => no value => no value

And as you'd expect, errors are output to stdout.


[2013-05-20 14:13:49] weirdan at gmail dot com

Those folders contain vanilla PHP code, with NO Debian patches applied.


[2013-05-20 14:08:21] weirdan at gmail dot com

Description:

Error messages in CLI should go to STDERR. This was the case with 5.3.x, but it 
doesn't seem to be the case with 5.4.*

Test script:
---
#!/bin/bash
for dir in `ls -d php-5*|grep -v tar`; do 
   echo -n "$dir: ";
   # the following line should output nothing 
   $dir/sapi/cli/php -n $(tempfile).php 2>/dev/null; 
   echo; 
done 


Expected result:

php-5.3.25: 
php-5.4.0:
php-5.4.15:
php-5.4.7:

Actual result:
--
php-5.3.25: 
php-5.4.0: Could not open input file: /tmp/filelm8WcG.php

php-5.4.15: Could not open input file: /tmp/filehmMkOG.php

php-5.4.7: Could not open input file: /tmp/fileSfJZ4E.php







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

Bug #64882 [Com]: 'Could not open input file' error message goes to STDOUT

2013-05-20 Thread weirdan at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64882&edit=1

 ID: 64882
 Comment by: weirdan at gmail dot com
 Reported by:weirdan at gmail dot com
 Summary:'Could not open input file' error message goes to
 STDOUT
 Status: Open
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Debian GNU/Linux
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

Those folders contain vanilla PHP code, with NO Debian patches applied.


Previous Comments:

[2013-05-20 14:08:21] weirdan at gmail dot com

Description:

Error messages in CLI should go to STDERR. This was the case with 5.3.x, but it 
doesn't seem to be the case with 5.4.*

Test script:
---
#!/bin/bash
for dir in `ls -d php-5*|grep -v tar`; do 
   echo -n "$dir: ";
   # the following line should output nothing 
   $dir/sapi/cli/php -n $(tempfile).php 2>/dev/null; 
   echo; 
done 


Expected result:

php-5.3.25: 
php-5.4.0:
php-5.4.15:
php-5.4.7:

Actual result:
--
php-5.3.25: 
php-5.4.0: Could not open input file: /tmp/filelm8WcG.php

php-5.4.15: Could not open input file: /tmp/filehmMkOG.php

php-5.4.7: Could not open input file: /tmp/fileSfJZ4E.php







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

[PHP-BUG] Bug #64882 [NEW]: 'Could not open input file' error message goes to STDOUT

2013-05-20 Thread weirdan at gmail dot com 
From: weirdan at gmail dot com
Operating system: Debian GNU/Linux
PHP version:  5.4.15
Package:  CGI/CLI related
Bug Type: Bug
Bug description:'Could not open input file' error message goes to STDOUT

Description:

Error messages in CLI should go to STDERR. This was the case with 5.3.x,
but it 
doesn't seem to be the case with 5.4.*

Test script:
---
#!/bin/bash
for dir in `ls -d php-5*|grep -v tar`; do 
   echo -n "$dir: ";
   # the following line should output nothing 
   $dir/sapi/cli/php -n $(tempfile).php 2>/dev/null; 
   echo; 
done 


Expected result:

php-5.3.25: 
php-5.4.0:
php-5.4.15:
php-5.4.7:

Actual result:
--
php-5.3.25: 
php-5.4.0: Could not open input file: /tmp/filelm8WcG.php

php-5.4.15: Could not open input file: /tmp/filehmMkOG.php

php-5.4.7: Could not open input file: /tmp/fileSfJZ4E.php


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

Bug #49382 [Com]: can't access DateTime->date

2010-08-04 Thread weirdan at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=49382&edit=1

 ID: 49382
 Comment by: weirdan at gmail dot com
 Reported by:klawd at kamundo dot de
 Summary:can't access DateTime->date
 Status: Assigned
 Type:   Bug
 Package:Feature/Change Request
 Operating System:   Debian GNU/Linux 5.0
 PHP Version:5.3.0
 Assigned To:derick
 Block user comment: N

 New Comment:

if this was not intended to work this way, why won't you just fix it so
that no 

properties are created as a result of print_r / Reflection::export() /
foreach() / 

property_exist / array cast?


Previous Comments:

[2010-03-07 20:22:06] der...@php.net

->date being available is actually a side-effect of support for
var_dump() here. I'll mark this as a feature request as it was not
intended to work.


[2009-08-27 07:52:37] klawd at kamundo dot de

Description:

Can not access property date of DateTime.

Reproduce code:
---
$dt=new DateTime('1742-05-23 00:00:00'); echo $dt->date;

gets me Notice: Undefined property: DateTime::$date



strangely though, this works:

$dt=new DateTime('1742-05-23 00:00:00'); print_r($dt); echo $dt->date;

DateTime Object ( [date] => 1742-05-23 00:00:00 [timezone_type] => 3
[timezone] => UTC ) 1742-05-23 00:00:00









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

#48361 [Com]: SplFileInfo::getPathinfo no returning info of path

2010-01-27 Thread weirdan at gmail dot com 
 ID:   48361
 Comment by:   weirdan at gmail dot com
 Reported By:  petercowburn at gmail dot com
 Status:   Assigned
 Bug Type: SPL related
 Operating System: OS X
 PHP Version:  5.3.0RC2
 Assigned To:  colder
 New Comment:

Also behavior has changed since 5.2 (where it at least behaved
according to documentation):

weir...@virtual-debian:/home/sam/trunk$ php -r
'var_dump(phpversion());
$f = new SplFileInfo("/usr/bin/php5"); 
$d = $f->getPathInfo(); 
var_dump($d->getRealPath());'

string(8) "5.2.12-2"
string(8) "/usr/bin"

weir...@virtual-debian:/home/sam/trunk$ sudo update-alternatives --set
php /usr/local/php/bin/php # switch to 5.3.1
update-alternatives: using /usr/local/php/bin/php to provide
/usr/bin/php (php) in manual mode.

weir...@virtual-debian:/home/sam/trunk$ php -r
'var_dump(phpversion());
$f = new SplFileInfo("/usr/bin/php5"); 
$d = $f->getPathInfo(); 
var_dump($d->getRealPath());'

string(5) "5.3.1"
string(13) "/usr/bin/php5"

weir...@virtual-debian:/home/sam/trunk$ ls -l /usr/bin/php5
-rwxr-xr-x 1 root root 5261500 Jan 11 19:36 /usr/bin/php5



The likely cause is the 'fix' for the
http://bugs.php.net/bug.php?id=45345 (which should have been rejected as
RTFM I believe).


Previous Comments:


[2009-08-19 15:30:07] tomasz dot kotecki at gmail dot com

This could be related... using 5.3.0. Using example from
http://uk3.php.net/manual/en/splfileinfo.getpath.php

getPath());


$info = new SplFileInfo('/usr/');
var_dump($info->getPath());?>

expected result:


string(8) "/usr/bin"
string(4) "/usr"

actual result:
--
string(8) "/usr/bin"
string(0) ""



[2009-06-16 22:24:03] petercowburn at gmail dot com

I downloaded a recent snap of PHP 5.3 (200906162030) which gives me PHP
5.3.0RC4 and amended the method definition which was using
spl_filesystem_object_get_pathname rather than
spl_filesystem_object_get_path.  With that function name changed, the
call to SplFileInfo::getPathInfo now appears to work as expected from
the description given in the documentation.

Reproduce code:
---
getPathInfo();
var_dump($parent_info->getRealPath());
?>

Expected result:

string(8) "/usr/bin"

Actual result:

string(8) "/usr/bin"

Diff file:
--
Index: spl_directory.c
===
RCS file: /repository/php-src/ext/spl/spl_directory.c,v
retrieving revision 1.45.2.27.2.23.2.43
diff -u -u -r1.45.2.27.2.23.2.43 spl_directory.c
--- spl_directory.c 4 Jun 2009 14:46:26 -   1.45.2.27.2.23.2.43
+++ spl_directory.c 16 Jun 2009 22:13:45 -
@@ -1176,7 +1176,7 @@
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|C", &ce) ==
SUCCESS) {
int path_len;
-   char *path = spl_filesystem_object_get_pathname(intern, 
&path_len
TSRMLS_CC);
+   char *path = spl_filesystem_object_get_path(intern, &path_len
TSRMLS_CC);
if (path) {
spl_filesystem_object_create_info(intern, path, 
path_len, 1, ce,
return_value TSRMLS_CC);
}



[2009-05-22 10:30:21] petercowburn at gmail dot com

Description:

It appears that using PHP5.3.0RC2-dev the SplFileInfo::getPathinfo
method just returns the SplFileInfo object on which it was called rather
than an SplFileInfo object for its path.



Reproduce code:
---
getPathInfo();
var_dump($parent_info->getRealPath());
?>

Expected result:

string(8) "/usr/bin"


Actual result:
--
string(12) "/usr/bin/php"





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

#44394 [Fbk->Opn]: Last two bytes missing from output

2008-03-11 Thread weirdan at gmail dot com 
 ID:   44394
 User updated by:  weirdan at gmail dot com
 Reported By:  weirdan at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Output Control
 Operating System: Windows XP
 PHP Version:  5.2.5
 New Comment:

not fixed on WinXP, tested with this script:
asd";
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();

Results:
C:\Windows\system32\cmd.exe /c .\php.exe q.php | more
5.2.6RC3-dev
asdhttp://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

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



----

[2008-03-10 16:03:29] weirdan at gmail dot com

Description:

It seems like a regression of http://bugs.php.net/bug.php?id=26862 -
two last bytes missing from output when using ob_flush() +
ob_end_clean(). ob_end_flush() works as expected though.

The same issue is observed on PHP 5.2.3 / Linux

Reproduce code:
---
asd";
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();

Expected result:

asd

Actual result:
--
asdhttp://bugs.php.net/?id=44394&edit=1

#44394 [NEW]: Last two bytes missing from output

2008-03-10 Thread weirdan at gmail dot com 
From: weirdan at gmail dot com
Operating system: Windows XP
PHP version:  5.2.5
PHP Bug Type: Output Control
Bug description:  Last two bytes missing from output

Description:

It seems like a regression of http://bugs.php.net/bug.php?id=26862 - two
last bytes missing from output when using ob_flush() + ob_end_clean().
ob_end_flush() works as expected though.

The same issue is observed on PHP 5.2.3 / Linux

Reproduce code:
---
asd";
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();

Expected result:

asd

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