Bug #53741 [Bgs]: DateTime, date_create, strtotime - wrong result on realtive date time string
Edit report at http://bugs.php.net/bug.php?id=53741&edit=1
ID: 53741
Updated by: der...@php.net
Reported by:metwo at gmx dot net
Summary:DateTime, date_create, strtotime - wrong result on
realtive date time string
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: inux 2.6.36.3 x86_64
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
And it's not a bug either. "midnight", "first day" and "last month" are
all separate items.
2011-01-13 17:23
"midnight" resets the time to 00:00: 2011-01-13 00:00
"first day" adds a day: 2011-01-14 00:00
"last month" removes a month: 2011-12-14 00:00
In PHP 5.3 you can do:
"midnight first day of last month" where "midnight", "first day of" and
"last month" are the tokens:
2011-01-13 17:23
"midnight" resets the time to 00:00: 2011-01-13 00:00
"last month" removes a month: 2011-12-14 00:00
"first day of" resets day to 1: 2011-12-01 00:00
Previous Comments:
[2011-01-14 04:47:44] ahar...@php.net
5.2 is no longer supported.
[2011-01-13 17:24:56] metwo at gmx dot net
Description:
parsing of relative date/time string "midnight first day last month"
returns a wrong result in php 5.2.17
Test script:
---
format('Y-m-d H:i:s') . "\n";
print date('Y-m-d H:i:s', strtotime('midnight first day last month'));
Expected result:
// relative to current date/time - 2011-01-13 17:23
DateTime Object
(
[date] => 2010-12-01 00:00:00
[timezone_type] => 3
[timezone] => Europe/Berlin
)
2010-12-01 00:00:00
2010-12-01 00:00:00
Actual result:
--
// relative to current date/time - 2011-01-13 17:23
DateTime Object
(
)
2010-12-14 00:00:00
2010-12-14 00:00:00
--
Edit this bug report at http://bugs.php.net/bug.php?id=53741&edit=1
Bug #53740 [Opn->Bgs]: DateTime, create_date, strtotime - wrong result on realtive date time string
Edit report at http://bugs.php.net/bug.php?id=53740&edit=1 ID: 53740 Updated by: der...@php.net Reported by:metwo at gmx dot net Summary:DateTime, create_date, strtotime - wrong result on realtive date time string -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: Linux 2.6.36.3 x86_64 PHP Version:5.3.5 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 was broken in < 5.3.3, you need to use the "first day of" phrase (and not use "first day"). "first day" means the same as "next day" (and always has). Previous Comments: [2011-01-13 17:12:53] metwo at gmx dot net Expected and actual result relative to current date/time - 2011-01-13 17:12 [2011-01-13 17:10:44] metwo at gmx dot net Description: parsing of "midnight first day last month" returns a wrong result in php 5.3.5 (worked correct in php 5.3.2) Test script: --- 2010-12-01 00:00:00 [timezone_type] => 3 [timezone] => Europe/Berlin ) 2010-12-01 00:00:00 Actual result: -- DateTime Object ( [date] => 2010-12-14 00:00:00 [timezone_type] => 3 [timezone] => Europe/Berlin ) 2010-12-14 00:00:00 -- Edit this bug report at http://bugs.php.net/bug.php?id=53740&edit=1
Bug #53737 [Csd->Bgs]: segfault / php crash on nl2br(object)
Edit report at http://bugs.php.net/bug.php?id=53737&edit=1 ID: 53737 Updated by: cataphr...@php.net Reported by:martin at veverka dot eu Summary:segfault / php crash on nl2br(object) -Status: Closed +Status: Bogus Type: Bug Package:Strings related Operating System: gentoo 1.12.14, FreeBSD 8.0 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I'm closing as bogus. If you find the problem, please submit a new bug report. Than you. Previous Comments: [2011-01-13 23:02:47] martin at veverka dot eu Seems that the segfault is caused by the object itself, I will post more details as soon as i know something. Sorry for the misleading description. [2011-01-13 15:58:20] cataphr...@php.net I can't reproduce: $ ~/php/php5.3-t/bin/php -r "echo nl2br(new mysqli);" Warning: nl2br() expects parameter 1 to be string, object given in Command line code on line 1 I also find no problem in nl2br (all pretty standard). Can you give more details? [2011-01-13 14:58:10] martin at veverka dot eu Description: Calling nl2br(any_object) causes segmentation fault and crashing php. Test script: --- http://bugs.php.net/bug.php?id=53737&edit=1
[PHP-BUG] Req #53745 [NEW]: cgi.discard_path option is missing from php.ini-production/development
From: Operating system: PHP version: 5.3.5 Package: PHP options/info functions Bug Type: Feature/Change Request Bug description:cgi.discard_path option is missing from php.ini-production/development Description: As of PHP 5.3.0, the --enable-discard-path configure option is no longer available and the preferred means to configure it is via php.ini (correct?). However, the cgi.discard_path option is not available in the stock php.ini-production and php.ini-development files that come with PHP 5.3.5. I wasn't sure if it was overlooked or if there was a reason behind it's exclusion. I couldn't find a related bug report, so I filed this one. Please excuse if this has already been discussed. -- Edit bug report at http://bugs.php.net/bug.php?id=53745&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53745&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53745&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53745&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53745&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53745&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53745&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53745&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53745&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53745&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53745&r=support Expected behavior: http://bugs.php.net/fix.php?id=53745&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53745&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53745&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53745&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53745&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53745&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53745&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53745&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53745&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53745&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53745&r=mysqlcfg
Req #53745 [Opn]: cgi.discard_path option is missing from php.ini-production/development
Edit report at http://bugs.php.net/bug.php?id=53745&edit=1 ID: 53745 User updated by:mcs at darkregion dot net Reported by:mcs at darkregion dot net Summary:cgi.discard_path option is missing from php.ini-production/development Status: Open Type: Feature/Change Request Package:PHP options/info functions PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Here is the list of core configure options that I'm following for this information: http://www.php.net/manual/en/configure.about.php Previous Comments: [2011-01-14 13:11:17] mcs at darkregion dot net Description: As of PHP 5.3.0, the --enable-discard-path configure option is no longer available and the preferred means to configure it is via php.ini (correct?). However, the cgi.discard_path option is not available in the stock php.ini-production and php.ini-development files that come with PHP 5.3.5. I wasn't sure if it was overlooked or if there was a reason behind it's exclusion. I couldn't find a related bug report, so I filed this one. Please excuse if this has already been discussed. -- Edit this bug report at http://bugs.php.net/bug.php?id=53745&edit=1
Bug #47441 [Com]: PHP segmentation fault on 'make test'
Edit report at http://bugs.php.net/bug.php?id=47441&edit=1 ID: 47441 Comment by: ashworth at us dot ibm dot com Reported by:jpilling at fortvale dot com Summary:PHP segmentation fault on 'make test' Status: Bogus Type: Bug Package:Compile Failure Operating System: zLinux - SLES 10 s390x 64bit PHP Version:5.3.0beta1 Block user comment: N Private report: N New Comment: I exported CFLAGS=-01 and that did not help. I modified my Makefile since gcc was complaining about -01. Changes to Makefile: removed -01 from CFLAGS_CLEAN added -01 to CFLAGS and left the exported CFLAGS set with -01 Compile completed successfully and make test worked as expected. Previous Comments: [2009-03-17 07:54:05] jpilling at fortvale dot com fixed by using: export CFLAGS=-O1 before compiling. Nothing to do with Zend, like I tried explaining. [2009-03-16 19:35:21] johan...@php.net Zend Optimizer is supported by Zend, not php.net [2009-02-23 00:16:11] jpilling at fortvale dot com anyone?? [2009-02-21 17:14:51] jpilling at fortvale dot com I dont understand.what I meant is that I want to install PHP with the --disable-debug option, and then once its installed properly I can add the Zend optimizer at a later date as an add on (to use the zend optimizer PHP has to be installed using the --disable-debug option) The backtrace i submitted was from PHP configured in the following way: ./configure --with-apxs2=/home/apache2/bin/apxs --with-mysql=/home/mysql --prefix=/home/apache2/php --disable-debug Are you saying I need to get a backtrace from PHP compiled as follows: ./configure --disable-all --disable-debug Please advise. regards [2009-02-20 13:18:56] j...@php.net Third strike. You're supposed to disable ALL 3rd party extensions. Especially any zend extensions. 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=47441 -- Edit this bug report at http://bugs.php.net/bug.php?id=47441&edit=1
Bug #50514 [Com]: failure while running make test
Edit report at http://bugs.php.net/bug.php?id=50514&edit=1 ID: 50514 Comment by: ashworth at us dot ibm dot com Reported by:pushpender007 at gmail dot com Summary:failure while running make test Status: Bogus Type: Bug Package:Compile Failure Operating System: SUSE Enterprise Server s390x PHP Version:5.2SVN-2009-12-18 (snap) Block user comment: N Private report: N New Comment: I exported CFLAGS=-01 and that did not help. I modified my Makefile since gcc was complaining about -01. Changes to Makefile: removed -01 from CFLAGS_CLEAN added -01 to CFLAGS and left the exported CFLAGS set with -01 Compile completed successfully and make test worked as expected. Previous Comments: [2011-01-12 01:54:04] ashworth at us dot ibm dot com I added --enable-debug and things seem to be working fine now. [2011-01-11 20:44:47] ashworth at us dot ibm dot com has anyone solved this yet? I cannot get past the phar issue without error, regardless of the version I use. [2010-01-05 05:18:18] pushpender007 at gmail dot com Hello ..Can you please confirm should I continue my installation or what else solution we have for the error in make test? Thanks [2009-12-22 15:16:21] pushpender007 at gmail dot com This is new result file with version 5.2.12. http://pushpender007.byethost6.com/php_test_results_20091222_1455.txt As you saying you are facing these errors too.Should I install as it is ,ignoring error? [2009-12-22 13:39:25] j...@php.net Well that explained a lot. First of all: You're testing 5.2.3? We're at 5.2.12 already, upgrade.. And next issue: Any tests failing fail also for me so nothing unexpected, we know about it, move along, nothing to see here.. 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=50514 -- Edit this bug report at http://bugs.php.net/bug.php?id=50514&edit=1
[PHP-BUG] Bug #53748 [NEW]: Using traits lead to a segmentation fault
From:
Operating system: Fedora core 11
PHP version: trunk-SVN-2011-01-14 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Using traits lead to a segmentation fault
Description:
The test script (Singleton pattern) leads to a Segmentation error
$ php test-trait.php
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Segmentation error
Test script:
---
See http://www.pastie.org/1460398
Expected result:
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Actual result:
--
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Segmentation error
--
Edit bug report at http://bugs.php.net/bug.php?id=53748&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53748&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53748&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53748&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53748&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53748&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53748&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53748&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53748&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53748&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53748&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53748&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53748&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53748&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53748&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53748&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53748&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53748&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53748&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53748&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53748&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53748&r=mysqlcfg
Bug #42424 [Com]: PHP5/PCRE fails to match long strings when ungreedy
Edit report at http://bugs.php.net/bug.php?id=42424&edit=1
ID: 42424
Comment by: php at richardneill dot org
Reported by:adam-phpbugs at adam dot gs
Summary:PHP5/PCRE fails to match long strings when ungreedy
Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Any
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
This isn't bogus; it should at the very least raise an error E_NOTICE.
I've just spent 7 hours tracking down a problem caused by this bug.
and generating you a helpful report:
http://www.richardneill.org/tmp/preg-error2.txt
I do understand the rationale for the limits (though personally, I think
they are 3 orders of magnitude too small, and I'd much rather my script
segfaulted rather than silently introducing subtle processing errors to
my data).
Could we at least make sure that with display_errors (E_ALL) we get some
kind of notification? At minimum, a notice would do, though ideally,
this should be a fatal error.
Previous Comments:
[2007-08-27 11:17:15] j...@php.net
In PHP 5.2.0 two new PCRE ini options were added to prevent possible
stack overflows and crashes. One of them is pcre.backtrack_limit.
When you set it high enough your script works as it did earlier (where
no such limits existed!)
$ php -dpcre.backtrack_limit=11 t.php
int(1)
int(1)
int(1)
int(1)
[2007-08-25 13:16:29] adam-phpbugs at adam dot gs
Description:
PHP5/PCRE will fail to match on long strings when UNGREEDY, the boundary
is around 100k of data.
FWIW, same results if you change x* to x+ down there.
Reproduce code:
---
%s",str_repeat("x",6));
var_dump(preg_match("#(x*?)#",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*?)#",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*)#U",$data));
$data=sprintf("%s",str_repeat("x",7));
var_dump(preg_match("#(x*)#",$data));
?>
Expected result:
all 4 expressions should match, this is what occurs with PHP 4.4.7.
Actual result:
--
under PHP 5.2.3:
only the first and 4th expression match
under PHP 4.4.7:
all 4 match.
--
Edit this bug report at http://bugs.php.net/bug.php?id=42424&edit=1
Bug #53748 [Opn->Fbk]: Using traits lead to a segmentation fault
Edit report at http://bugs.php.net/bug.php?id=53748&edit=1
ID: 53748
Updated by: johan...@php.net
Reported by:contact at chdemko dot com
Summary:Using traits lead to a segmentation fault
-Status: Open
+Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Fedora core 11
PHP Version:trunk-SVN-2011-01-14 (SVN)
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.
what options are you using to compile PHP? - It works for me without
segfault:
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Previous Comments:
[2011-01-14 16:55:46] contact at chdemko dot com
Description:
The test script (Singleton pattern) leads to a Segmentation error
$ php test-trait.php
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Segmentation error
Test script:
---
See http://www.pastie.org/1460398
Expected result:
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Actual result:
--
int(1)
int(2)
array(1) {
[1]=>
int(2)
}
Segmentation error
--
Edit this bug report at http://bugs.php.net/bug.php?id=53748&edit=1
Bug #53572 [Opn]: Bug appeared in php 5.2.15, FastCGI
Edit report at http://bugs.php.net/bug.php?id=53572&edit=1 ID: 53572 User updated by:admin at xaker1 dot ru Reported by:admin at xaker1 dot ru Summary:Bug appeared in php 5.2.15, FastCGI Status: Open Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 8.1 PHP Version:5.2.16 Block user comment: N Private report: N New Comment: Error disappears if you disable open_basedir Previous Comments: [2010-12-20 19:36:53] markusb at gmx dot at Same probleme We use php (cgi) and open_basedir > all php scrips > No input file specified. [2010-12-19 09:05:26] admin at xaker1 dot ru The problem exists on php 5.2.15 and php 5.2.16. I'm using php 5.2.14, as work is needed for all sites. php.ini on the affected account: register_globals = Off display_errors = Off log_errors = On max_execution_time = 30 memory_limit = 128M upload_max_filesize = 16M post_max_size = 16M session.save_path = "/ home/saki2/data/tmp" upload_tmp_dir = "/ home/saki2/data/tmp" open_basedir = "/ home/saki2: / tmp: / var / tmp" ; [suhosin] ; suhosin.log.syslog = E_ALL & ~ S_SQL ; suhosin.log.sapi = E_ALL & ~ S_SQL ; suhosin.executor.include.max_traversal = 4 ; suhosin.executor.func.blacklist = popen, dl, passthru, system, exec, proc_open, shell_exec, proc_close, symlink ; WARNING ; Or eAccelerator or Zend!!! ; Not twice!!! ; [eAccelerator] ; zend_extension = "/ usr/local/lib/php/20060613/eaccelerator.so" ; eaccelerator.cache_dir = "/ home/saki2/data/tmp" ; eaccelerator.debug = "0" ; eaccelerator.shm_size = "16" ; [Zend] ; zend_optimizer.optimization_level = 15 ; zend_extension_manager.optimizer = "/ usr/local/lib/php/20060613/Optimizer" ; zend_extension_manager.optimizer_ts = "/ usr/local/lib/php/20060613/Optimizer_TS" ; zend_extension = "/ usr/local/lib/php/20060613/ZendExtensionManager.so" ; zend_extension_ts = "/ usr/local/lib/php/20060613/ZendExtensionManager_TS.so" php.ini in the working account: register_globals= Off display_errors= On log_errors= On max_execution_time= 900 memory_limit= 512M upload_max_filesize= 16M post_max_size = 16M session.save_path = "/home/bravohost/data/tmp" upload_tmp_dir="/home/bravohost/data/tmp" open_basedir = "/home/bravohost:/tmp:/var/tmp" ;[suhosin] ;suhosin.log.syslog = E_ALL & ~S_SQL ;suhosin.log.sapi = E_ALL & ~S_SQL ;suhosin.executor.include.max_traversal = 4 ;suhosin.executor.func.blacklist = popen,dl,passthru,system,exec,proc_open,shell_exec,proc_close,symlink ; WARNING ; or eAccelerator or Zend!!! ; not twice!!! [eAccelerator] zend_extension="/usr/local/lib/php/20060613/eaccelerator.so" eaccelerator.cache_dir="/home/bravohost/data/tmp" eaccelerator.debug="0" eaccelerator.shm_size="16" ;[Zend] ;zend_optimizer.optimization_level=15 ;zend_extension_manager.optimizer="/usr/local/lib/php/20060613/Optimizer" ;zend_extension_manager.optimizer_ts="/usr/local/lib/php/20060613/Optimizer_TS" ;zend_extension="/usr/local/lib/php/20060613/ZendExtensionManager.so" ;zend_extension_ts="/usr/local/lib/php/20060613/ZendExtensionManager_TS.so ;extension = filter.so php modules are used: [PHP Modules] bcmath bz2 calendar ctype curl date dom filter gd gettext hash iconv imap ionCube Loader json libxml mbstring mcrypt mhash mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite standard suhosin tokenizer xml xmlreader xmlwriter Zend Optimizer zip zlib [Zend Modules] Zend Extension Manager Zend Optimizer the ionCube PHP Loader [2010-12-18 22:14:48] cataphr...@php.net We'd need more information than what you gave. First, are you using 5.2.15 or 5.2.16. If you're using 5.2.15, upgrade. Then, what exactly is causing this (not a vague it may be root folder or name/group or open_basedir) and, preferably, steps to reproduce, would go a long way. Thanks. [2010-12-18 18:03:27] admin at xaker1 dot ru If you downgrade to 5.2.14, the error disappears. At the moment the causes of errors are found, ask for help. [2010-12-18 18:02:10] admin at xaker1 dot ru Description: Any php script Test script: --- Actual result: -- The script fails, the message "No input file specified.". Sometimes the script works. The problem occurred in 2 of the account's 300. Accounts differ in the root folder, name\group file and set open_basedir. If you downgrade to 5.2.1914, the error disappears. At the moment the causes of errors are fou
[PHP-BUG] Bug #53750 [NEW]: dynamic variable name problem
From: Operating system: ubuntu PHP version: 5.2.17 Package: Arrays related Bug Type: Bug Bug description:dynamic variable name problem Description: example 1: php > $a = new stdclass(); php > $a->arr = array(1,2,3); php > $arr = 'arr'; php > print_r($a->$arr); Array ( [0] => 1 [1] => 2 [2] => 3 ) php > print_r($a->$arr[0]); php > example 2: php > $arr = array(1,2,3); php > $a = 'arr'; php > print_r($$a); Array ( [0] => 1 [1] => 2 [2] => 3 ) php > print_r($$a[0]); arr php > print_r($$a[1]); php > Test script: --- $a = new stdclass(); $a->arr = array(1,2,3); $arr = 'arr'; print_r($a->$arr); print_r($a->$arr[0]) Expected result: cant access array elements with a dynamic variable name. -- Edit bug report at http://bugs.php.net/bug.php?id=53750&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53750&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53750&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53750&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53750&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53750&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53750&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53750&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53750&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53750&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53750&r=support Expected behavior: http://bugs.php.net/fix.php?id=53750&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53750&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53750&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53750&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53750&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53750&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53750&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53750&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53750&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53750&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53750&r=mysqlcfg
[PHP-BUG] Req #53752 [NEW]: Make __construct non final
From:
Operating system: Windows 7
PHP version: Irrelevant
Package: *Extensibility Functions
Bug Type: Feature/Change Request
Bug description:Make __construct non final
Description:
In order to extends the OAuth object, make the constructor non final so we
can
redefine __constrcut().
This is useful for framework like drupal, and you can then create an
OAuthAdapter
(which extends OAuth pecl) and instantiate it by giving a module name.
e.g. new OAuthAdapter("facebook"); consumer_key and secret are stored by
drupal
convention so we can skip this step for développment and make the lib very
dev-
friendly. (the pattern adapter allows redefinition in case the user don't
have
control on his webserver - shared environment for instance).
Sylvain Lecoy
--
Edit bug report at http://bugs.php.net/bug.php?id=53752&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53752&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53752&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53752&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53752&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53752&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53752&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53752&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53752&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53752&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53752&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53752&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53752&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53752&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53752&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53752&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53752&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53752&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53752&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53752&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53752&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53752&r=mysqlcfg
Req #53752 [Opn]: Make __construct non final
Edit report at http://bugs.php.net/bug.php?id=53752&edit=1
ID: 53752
User updated by:sylvain dot lecoy at gmail dot com
Reported by:sylvain dot lecoy at gmail dot com
Summary:Make __construct non final
Status: Open
Type: Feature/Change Request
Package:*Extensibility Functions
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
class OAuthAdapter extends OAuth implements DrupalOAuthClient {
private $mModule;
static function construct($module, $signature_method = NULL,
$auth_type =
NULL) {
$consumer_key = variable_get($module . '_consumer_key', '');
$consumer_secret = variable_get($module . '_consumer_secret', '');
$oauth = new OAuthAdapter($consumer_key, $consumer_secret,
$signature_method, $auth_type);
$oauth->mModule = $module;
// If the user is not anonymous (can happen with cron auto-sync
tasks).
if ($GLOBALS['user']->uid != 0) {
$oauth->setCaller($GLOBALS['user']->uid);
}
return $oauth;
}
}
Here is some code to illustrate a work around, but using __construct
will be a
lot better.
I am using 0.99.9 (on windows machine dev) maybe it has been changed on
1.0.0 ?
Previous Comments:
[2011-01-14 18:35:46] sylvain dot lecoy at gmail dot com
Description:
In order to extends the OAuth object, make the constructor non final so
we can
redefine __constrcut().
This is useful for framework like drupal, and you can then create an
OAuthAdapter
(which extends OAuth pecl) and instantiate it by giving a module name.
e.g. new OAuthAdapter("facebook"); consumer_key and secret are stored by
drupal
convention so we can skip this step for développment and make the lib
very dev-
friendly. (the pattern adapter allows redefinition in case the user
don't have
control on his webserver - shared environment for instance).
Sylvain Lecoy
--
Edit this bug report at http://bugs.php.net/bug.php?id=53752&edit=1
Bug #53743 [Com]: Crypt() returns inconsistant results on numeric strings
Edit report at http://bugs.php.net/bug.php?id=53743&edit=1
ID: 53743
Comment by: daniel dot macdonald at designory dot com
Reported by:daniel dot macdonald at designory dot com
Summary:Crypt() returns inconsistant results on numeric
strings
Status: Open
Type: Bug
Package:*Encryption and hash functions
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Another test case producing weird results?:
code:
$salt = '$1$abcdefgh$';
$pass = '123';
for ($i=0; $i<3; $i++) {
echo crypt($pass, $salt)."\n";
}
echo crypt($pass, $salt)."\n";
outputs:
$1$abcdefgh$JwVLNLvq4bwIKuyv1qm8L0
$1$abcdefgh$JwVLNLvq4bwIKuyv1qm8L0
$1$abcdefgh$JwVLNLvq4bwIKuyv1qm8L0
$1$abcdefgh$ohde1Lc7jN2GJjhi5UKGV0
Previous Comments:
[2011-01-14 02:59:02] daniel dot macdonald at designory dot com
Description:
---
>From manual page: http://www.php.net/function.crypt#Return Values
---
The crypt() function, when using MD5, returns different results if the
input string is all numeric.
Test script:
---
\n";
echo crypt($pass, $salt)."\n";
echo crypt($pass2, $salt)."\n";
echo crypt($pass2, $salt)."\n";
?>
Expected result:
$1$abcdefgh$OTo2MhKVLtpE9bkEycLQf0
$1$abcdefgh$OTo2MhKVLtpE9bkEycLQf0
$1$abcdefgh$PiPnB9KJsYjPIXtoia0WK/
$1$abcdefgh$PiPnB9KJsYjPIXtoia0WK/
Actual result:
--
$1$abcdefgh$OTo2MhKVLtpE9bkEycLQf0
$1$abcdefgh$JwVLNLvq4bwIKuyv1qm8L0
$1$abcdefgh$PiPnB9KJsYjPIXtoia0WK/
$1$abcdefgh$PiPnB9KJsYjPIXtoia0WK/
--
Edit this bug report at http://bugs.php.net/bug.php?id=53743&edit=1
Req #53752 [Opn->Bgs]: Make __construct non final
Edit report at http://bugs.php.net/bug.php?id=53752&edit=1
ID: 53752
Updated by: cataphr...@php.net
Reported by:sylvain dot lecoy at gmail dot com
Summary:Make __construct non final
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:*Extensibility Functions
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Please report it at http://pecl.php.net/package/oauth instead.
Previous Comments:
[2011-01-14 18:39:55] sylvain dot lecoy at gmail dot com
class OAuthAdapter extends OAuth implements DrupalOAuthClient {
private $mModule;
static function construct($module, $signature_method = NULL,
$auth_type =
NULL) {
$consumer_key = variable_get($module . '_consumer_key', '');
$consumer_secret = variable_get($module . '_consumer_secret', '');
$oauth = new OAuthAdapter($consumer_key, $consumer_secret,
$signature_method, $auth_type);
$oauth->mModule = $module;
// If the user is not anonymous (can happen with cron auto-sync
tasks).
if ($GLOBALS['user']->uid != 0) {
$oauth->setCaller($GLOBALS['user']->uid);
}
return $oauth;
}
}
Here is some code to illustrate a work around, but using __construct
will be a
lot better.
I am using 0.99.9 (on windows machine dev) maybe it has been changed on
1.0.0 ?
[2011-01-14 18:35:46] sylvain dot lecoy at gmail dot com
Description:
In order to extends the OAuth object, make the constructor non final so
we can
redefine __constrcut().
This is useful for framework like drupal, and you can then create an
OAuthAdapter
(which extends OAuth pecl) and instantiate it by giving a module name.
e.g. new OAuthAdapter("facebook"); consumer_key and secret are stored by
drupal
convention so we can skip this step for développment and make the lib
very dev-
friendly. (the pattern adapter allows redefinition in case the user
don't have
control on his webserver - shared environment for instance).
Sylvain Lecoy
--
Edit this bug report at http://bugs.php.net/bug.php?id=53752&edit=1
[PHP-BUG] Bug #53753 [NEW]: fread on unix doman socket returns read numeric value 0 as false
From: Operating system: UNIX PHP version: 5.3.5 Package: Streams related Bug Type: Bug Bug description:fread on unix doman socket returns read numeric value 0 as false Description: --- >From manual page: http://www.php.net/function.fread#Return Values --- Trying to read from a unix domain socket. The content being received is a single numeric value 0 which fread returns as false and is not detected even with (false === $ret). However, if the number is changed to single numeric value 1, then fread returns 1 as a string as expected and (1 === $ret) fails confirming that the $ret is actually a string. -- Edit bug report at http://bugs.php.net/bug.php?id=53753&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53753&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53753&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53753&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53753&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53753&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53753&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53753&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53753&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53753&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53753&r=support Expected behavior: http://bugs.php.net/fix.php?id=53753&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53753&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53753&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53753&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53753&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53753&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53753&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53753&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53753&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53753&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53753&r=mysqlcfg
[PHP-BUG] Req #53754 [NEW]: Modify headers_list() to return an array of set headers in CLI SAPI
From:
Operating system: Ubuntu Server 10.0
PHP version: 5.3.5
Package: CGI related
Bug Type: Feature/Change Request
Bug description:Modify headers_list() to return an array of set headers in CLI
SAPI
Description:
Calling headers_list() from the CLI version of PHP always returns an empty
array, ignoring the results of previous calls to header(), despite the fact
that they are already tracked internally.
As some background, I'm attempting to write a pure PHP bootstrap
development HTTP server to help programmers easily create new development
environments and for lightweight standalone webapps that don't need a fully
featured web-server to deploy.
One of the things I'm trying to accomplish with this is to enable out of
the box usage on various *nix distros and Mac OSX. The PHP-CGI SAPI is
perfect for my project, but it isn't always installed by default (certainly
not on OSX), so I'm attempting to make it work with the CLI version.
I've managed to work around most of the limitations I've run up against,
but this headers_list() always returning an empty array is a complete
show-stopper. Without being able to retrieve the list, apps that set any
kind of custom headers (including cookies), can never work correctly.
I've attached a one-line patch to enable headers_list() to function in the
CLI SAPI. Another (probably better) option would be to create an ini file
setting to determine which behavior to exhibit. I'd be happy to do the dev
work for that and submit the revised patch.
Test script:
---
#!/usr/bin/php
string(23) "X-Powered-By: PHP/5.3.5"
[1]=>
string(14) "Location: asdf"
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/bug.php?id=53754&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53754&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53754&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53754&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53754&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53754&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53754&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53754&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53754&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53754&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53754&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53754&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53754&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53754&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53754&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53754&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53754&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53754&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53754&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53754&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53754&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53754&r=mysqlcfg
Bug #53753 [Opn->Fbk]: fread on unix doman socket returns read numeric value 0 as false
Edit report at http://bugs.php.net/bug.php?id=53753&edit=1 ID: 53753 Updated by: cataphr...@php.net Reported by:akshaydeepak at gmail dot com Summary:fread on unix doman socket returns read numeric value 0 as false -Status: Open +Status: Feedback Type: Bug Package:Streams related Operating System: UNIX PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2011-01-14 21:26:00] akshaydeepak at gmail dot com Description: --- >From manual page: http://www.php.net/function.fread#Return Values --- Trying to read from a unix domain socket. The content being received is a single numeric value 0 which fread returns as false and is not detected even with (false === $ret). However, if the number is changed to single numeric value 1, then fread returns 1 as a string as expected and (1 === $ret) fails confirming that the $ret is actually a string. -- Edit this bug report at http://bugs.php.net/bug.php?id=53753&edit=1
Bug #30036 [Com]: In_Array not works when array contain booleans
Edit report at http://bugs.php.net/bug.php?id=30036&edit=1
ID: 30036
Comment by: miker at yahoo-inc dot com
Reported by:marek at lewczuk dot com
Summary:In_Array not works when array contain booleans
Status: Bogus
Type: Bug
Package:Arrays related
Operating System: Windows
PHP Version:4.3.8
Block user comment: N
Private report: N
New Comment:
sni...@php.net, can you describe the reasoning behind this behavior?
Currently, I'm inclined to agree with Marek that this is bug-like
behavior. Thank you. Mike.
Previous Comments:
[2004-09-15 11:36:33] marek at lewczuk dot com
Right, it works with 3rd parameter, but it is not the point - is string
"test" equal to boolean "true" ? Even if we are not comparing variable
types, then "test" is not equal to "1". For example, I have an array
with strings, integers, boolean - I'm looking for any "123" value - I
don't care if this is an integer or string - the value is important. In
this case, I can't use in_array with 3rd parameter, because it will not
find all all correct values.
examples:
in_array('232', array(232, '232', true))
this will return true - correct
in_array('232', array(232, true), true)
this will return false - correct
in_array('232', array(233, '233', true))
this will return true - wrong
In my opinion this is not correct behavior...
[2004-09-15 10:56:57] sni...@php.net
Use the 3rd optional parameter (for strict search) which makes
in_array() to check the type too. NOT a bug.
[2004-09-09 10:04:27] marek at lewczuk dot com
Description:
When you have an array with boolean values, then in_array will always
return true.
Reproduce code:
---
print in_array("test it", array(true, true, "sdsd" => true))
Expected result:
should return false
Actual result:
--
true
--
Edit this bug report at http://bugs.php.net/bug.php?id=30036&edit=1
[PHP-BUG] Bug #53755 [NEW]: FILTER_SANITIZE_STRING truncates string with unmatched
From:
Operating system: Ubuntu/Linux
PHP version: 5.3.5
Package: Filter related
Bug Type: Bug
Bug description:FILTER_SANITIZE_STRING truncates string with unmatched <
Description:
If a string containing an unmatched "<" character is run through the
FILTER_SANITIZE_STRING filter the string is truncated at the <.
The problem seems to stem from the last parameter in the call to
php_strip_tags_ex(). That parameter tells php_strip_tags_ex() ignore spaces
trailing "<" characters. I checked how php_strip_tags_ex() is called in the
PHP function strip_tags() and it tells php_strip_tags_ex to allow spaced
after a "<".
See ext/filter/santitizing_filters.c line 203 and ext/standard/string.c
line 4023 in PHP 5.3.5.
Test script:
---
echo filter_var('four is < 6', FILTER_SANITIZE_STRING);
Expected result:
four is < 6
Actual result:
--
four is
--
Edit bug report at http://bugs.php.net/bug.php?id=53755&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53755&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53755&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53755&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53755&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53755&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53755&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53755&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53755&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53755&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53755&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53755&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53755&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53755&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53755&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53755&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53755&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53755&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53755&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53755&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53755&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53755&r=mysqlcfg
Bug #53755 [Com]: FILTER_SANITIZE_STRING truncates string with unmatched
Edit report at http://bugs.php.net/bug.php?id=53755&edit=1
ID: 53755
Comment by: pgarvin76 at gmail dot com
Reported by:pgarvin76 at gmail dot com
Summary:FILTER_SANITIZE_STRING truncates string with
unmatched <
Status: Open
Type: Bug
Package:Filter related
Operating System: Ubuntu/Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
The bugtracker would let me upload my diff so I created a Gist for it on
Github.
https://gist.github.com/780577
I tested this solves the problem on 5.3.5.
Also here is a PHPT test for the bug.
https://gist.github.com/780574
Previous Comments:
[2011-01-15 01:40:56] pgarvin76 at gmail dot com
Description:
If a string containing an unmatched "<" character is run through the
FILTER_SANITIZE_STRING filter the string is truncated at the <.
The problem seems to stem from the last parameter in the call to
php_strip_tags_ex(). That parameter tells php_strip_tags_ex() ignore
spaces trailing "<" characters. I checked how php_strip_tags_ex() is
called in the PHP function strip_tags() and it tells php_strip_tags_ex
to allow spaced after a "<".
See ext/filter/santitizing_filters.c line 203 and ext/standard/string.c
line 4023 in PHP 5.3.5.
Test script:
---
echo filter_var('four is < 6', FILTER_SANITIZE_STRING);
Expected result:
four is < 6
Actual result:
--
four is
--
Edit this bug report at http://bugs.php.net/bug.php?id=53755&edit=1
