Bug #54851 [Com]: DateTime::createFromFormat, $format=='D' or $format=='l' Always Returns Today.
Edit report at http://bugs.php.net/bug.php?id=54851edit=1
ID: 54851
Comment by: mats dot lindh at gmail dot com
Reported by:phpbugs at nicholassloan dot com
Summary:DateTime::createFromFormat, $format=='D' or
$format=='l' Always Returns Today.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X
PHP Version:trunk-SVN-2011-05-18 (SVN)
Block user comment: N
Private report: N
New Comment:
The issue seems to be that there is currently no parsing done for the
D/l parameters. I've added a patch and a test that seems to fix the
issue.
Previous Comments:
[2011-05-19 00:51:31] phpbugs at nicholassloan dot com
Description:
If the format only includes a day string ('D' or 'l'), it is ignored,
and a
DateTime instance for the current date/time is returned. Maybe I'm a
stupid idiot,
but I would expect either an error, or for it to return a DateTime
object for the
next occurrence of the given day (similar to
\DateTime::__construct('Monday');)
Test script:
---
?php
$date = new \DateTime('tomorrow');
$date2 = \DateTime::createFromFormat('D', $date-format('D'));
var_dump($date);
var_dump($date-format('D'));
var_dump($date2);
var_dump($date2-format('D'));
Expected result:
I expect the same date/day to be selected in both cases.
Actual result:
--
object(DateTime)#1 (3) {
[date]=
string(19) 2011-05-19 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/New_York
}
string(3) Thu
object(DateTime)#2 (3) {
[date]=
string(19) 2011-05-18 18:49:33
[timezone_type]=
int(3)
[timezone]=
string(16) America/New_York
}
string(3) Wed
--
Edit this bug report at http://bugs.php.net/bug.php?id=54851edit=1
[PHP-BUG] Bug #54727 [NEW]: ob_flush() before output_reset_rewrite_vars() results in data loss
From:
Operating system: *
PHP version: trunk-SVN-2011-05-13 (SVN)
Package: Output Control
Bug Type: Bug
Bug description:ob_flush() before output_reset_rewrite_vars() results in data
loss
Description:
The test for http://bugs.php.net/bug.php?id=26862 currently fails and
results in the last echo statement (everything after ob_flush() and
output_reset_rewrite_vars()) to get lost.
A variant of the issue was reintroduced after the output buffering
rewrite.
This seems to happen because the output is never handled if there is no
rewrite variables to process and there is no active buffer with contents.
The output chars still needs to returned as handled.
The patch also contains a small change in the test to better differentiate
the two echo statements.
Test script:
---
Based on: ext/session/tests/bug26862.phpt
?php
session_start();
output_add_rewrite_var('var', 'value');
echo 'a href=file-first.phplink/a';
ob_flush();
output_reset_rewrite_vars();
echo 'a href=file-second.phplink/a';
Expected result:
a href=file-first.php?var=valuelink/aa
href=file-second.phplink/a
Actual result:
--
a href=file-first.php?var=valuelink/a
--
Edit bug report at http://bugs.php.net/bug.php?id=54727edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54727r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54727r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54727r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54727r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54727r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54727r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54727r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54727r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54727r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54727r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54727r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54727r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54727r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54727r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54727r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54727r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54727r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54727r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54727r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54727r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54727r=mysqlcfg
[PHP-BUG] Bug #54719 [NEW]: Serialization tests fail to set serialize_precision
From: Operating system: Linux PHP version: trunk-SVN-2011-05-12 (SVN) Package: Unknown/Other Function Bug Type: Bug Bug description:Serialization tests fail to set serialize_precision Description: The tests for the serialization module fails to set the INI value for serialize_precision before running the tests, resulting in failed tests if the default precision is used (if the tests are run before make install and no php.ini file is available). Test script: --- make test TESTS=ext/standard/tests/serialize Expected result: Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 50 ( 98.0%) (100.0%) Actual result: -- Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:5 ( 9.8%) ( 10.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 45 ( 88.2%) ( 90.0%) -- Edit bug report at http://bugs.php.net/bug.php?id=54719edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54719r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54719r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54719r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54719r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54719r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54719r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54719r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54719r=needscript Try newer version: http://bugs.php.net/fix.php?id=54719r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54719r=support Expected behavior: http://bugs.php.net/fix.php?id=54719r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54719r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54719r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54719r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54719r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54719r=dst IIS Stability: http://bugs.php.net/fix.php?id=54719r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54719r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54719r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54719r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54719r=mysqlcfg
Bug #51344 [Com]: FILTER_NULL_ON_FAILURE flag automatically set in filter_input() functions.
Edit report at http://bugs.php.net/bug.php?id=51344edit=1 ID: 51344 Comment by: mats dot lindh at gmail dot com Reported by: pravila at alumni dot calpoly dot edu Summary: FILTER_NULL_ON_FAILURE flag automatically set in filter_input() functions. Status: Open Type: Bug Package: Filter related Operating System: Linux PHP Version: 5.2.13 New Comment: Patch to solve issue has been added. Patch is against current trunk but can probably be applied cleanly against 5.2 and 5.3 too. Issue stems from a simple error where RETURN_NULL(); and RETURN_FALSE; statements seems to have gotten mixed up. Test is also attached in patch, based on the example in the bug report. Previous Comments: [2010-03-21 18:02:46] pravila at alumni dot calpoly dot edu Description: * This is different than bug http://bugs.php.net/bug.php?id=41305 * The filter_var() vs. the filter_input() behave differently when using the FILTER_VALIDATE_BOOLEAN filter when the variable/input doesn't exist. More specifically, it seems as if the FILTER_NULL_ON_FAILURE flag is set automatically in the filter_input() function. (Note: same behavior for filter_var_array() vs. filter_input_array()). From PHPINFO(): filter.default = unsafe_raw filter.default_flags = no value Revision: 1.52.2.39.2.16 Test script: --- ?php // example.com/script.php?arg1=yesarg3=no // filtering by variable $var1 = filter_var($_GET[arg1], FILTER_VALIDATE_BOOLEAN); $var2 = filter_var($_GET[arg2], FILTER_VALIDATE_BOOLEAN); $var3 = filter_var($_GET[arg3], FILTER_VALIDATE_BOOLEAN); // filtering by input $input1 = filter_input(INPUT_GET, arg1, FILTER_VALIDATE_BOOLEAN); $input2 = filter_input(INPUT_GET, arg2, FILTER_VALIDATE_BOOLEAN); $input3 = filter_input(INPUT_GET, arg3, FILTER_VALIDATE_BOOLEAN); // as expected... var_dump($var1); // bool(true) var_dump($var2); // bool(false) var_dump($var3); // bool(false) // NULL is not an expected return unless the FILTER_NULL_ON_FAILURE flag is set... var_dump($input1);// bool(true) var_dump($input2);// NULL var_dump($input3);// bool(false) ? Expected result: As per the documentation, we expect the output of the code above to be: bool(true) bool(false) bool(false) bool(true) bool(false) bool(false) Actual result: -- Even though the FILTER_NULL_ON_FAILURE flag is NOT set, we DO get a NULL value in the output: bool(true) bool(false) bool(false) bool(true) NULL bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=51344edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: mats dot lindh at gmail dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!
Previous Comments:
[2009-09-03 10:10:14] phpstuff at cresstone dot com
I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.
Thanks.
[2009-09-02 23:26:04] paj...@php.net
I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.
I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).
[2009-09-02 22:59:59] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287975
Log: - #48746, len includes null already
[2009-09-02 21:29:08] phpstuff at cresstone dot com
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo dumping: scandir('mounted_volume')\n;
var_dump(scandir('mounted_volume'));
echo dumping: scandir('mounted_volume\\file1')\n;
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=
string(12) $RECYCLE.BIN
[1]=
string(4) dir1
[2]=
string(4) dir2
[3]=
string(5) file1
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: mklink mounted_volume y: everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation (mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\) that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
[2009-09-02 10:35:32] paj...@php.net
Can't reproduce here. Which OS are you using for this test?
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746edit=1
#48778 [Com]: Files on NTFS Mounted Volumes (Junctions) inaccessible
ID: 48778
Comment by: mats dot lindh at gmail dot com
Reported By: cs at koch-aplsystems dot de
Status: Feedback
Bug Type: *General Issues
Operating System: win32 only - XP SP3
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
(If the formatting of this comment gets fubared, I've created a copy
online: http://e-mats.org/resources/php-5.3-windows-junctions.txt)
Here's a simple test opening a file in PHP instead (I'm guessing that
the first open file in the php binary ignores stuff such as streams,
etc. and uses another codepath):
test.php
?php
var_dump(file_get_contents(testcase-junction/test.txt));
var_dump(file_get_contents(testcase/test.txt));
With a snapshot downloaded today vs PHP 5.2.5 (from WAMP, which was the
only old installation I had around):
F:\temp\php-5.3-win32-VC9-x86-latestphp -v
PHP 5.3.1-dev (cli) (built: Aug 10 2009 19:52:21)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
F:\temp\php-5.3-win32-VC9-x86-latestmkdir testcase
F:\temp\php-5.3-win32-VC9-x86-latestcd testcase
F:\temp\php-5.3-win32-VC9-x86-latest\testcaseecho This is a file
test.txt
F:\temp\php-5.3-win32-VC9-x86-latest\testcasecd ..
F:\temp\php-5.3-win32-VC9-x86-latestjunction testcase-junction
testcase
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: F:\temp\php-5.3-win32-VC9-x86-latest\testcase-junction
Targetted at: F:\temp\php-5.3-win32-VC9-x86-latest\testcase
F:\temp\php-5.3-win32-VC9-x86-latestphp test.php
Warning: file_get_contents(testcase-junction/test.txt): failed to open
stream: No such file or directory in
F:\temp\php-5.3-win32-VC9-x86-latest\test.php on line 2
bool(false)
string(19) This is a file
F:\temp\php-5.3-win32-VC9-x86-latestdir
[snip]
10.08.2009 22:40DIR testcase
10.08.2009 22:41JUNCTION testcase-junction
F:\temp\php5.2.5php -v
PHP 5.2.5 (cli) (built: Nov 8 2007 23:18:51)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
F:\temp\php5.2.5mkdir testcase
F:\temp\php5.2.5cd testcase
F:\temp\php5.2.5\testcaseecho This is a file test.txt
F:\temp\php5.2.5\testcasecd ..
F:\temp\php5.2.5junction testcase-junction testcase
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: F:\temp\php5.2.5\testcase-junction
Targetted at: F:\temp\php5.2.5\testcase
F:\temp\php5.2.5php test.php
string(19) This is a file
string(19) This is a file
F:\temp\php5.2.5dir
[snip]
10.08.2009 22:46DIR testcase
10.08.2009 22:46JUNCTION testcase-junction
(This does not involve the DocumentRoot as in the first test case, and
should hopefully be easier to isolate)
Previous Comments:
[2009-08-10 15:33:37] paj...@php.net
Can you using CLI or FastCGI please?
Using:
F:\wc63dir c:\temp\
10.08.2009 17:30JUNCTION foo [f:\]
and this call:
php-cgi.exe c:\temp\foo\wc63\http\pwe\t.php
it works just fine (CLI/FCGI).
It could be an apache only problem.
[2009-08-09 16:20:58] tswsl1989 at sucs dot org
Problem also occurs when trying to access a junction contained within
the DocumentRoot of Apache.
Apache/2.2.11 (Win32) PHP/5.3.0
NTFS 3.1 on both drives.
Error occurs accessing docroot\igal, where docroot\igal is a
junction to O:\
[2009-07-20 20:33:57] phpstuff at cresstone dot com
Reproduced, some things seem ok on previous versions.
Where the NTFS folder 'c:\mnt\drive1' is a mounted drive...
Using 5.3, is_dir('c:\mnt\drive1') returns false, and other filesystem
functions like scandir fail. However, using the 5.2.10 zip package,
is_dir returns true and scandir correctory enumerates the directory.
[2009-07-09 20:38:23] Steve at b-en-e dot com
Confirmed here. 5.2.8 does not have this problem, but 5.2.10 does, so
it was introduced in the previous versions.
Removing the junction from the picture solves the problem.
Note that it is not only the source files: if the error log is directed
to a junctioned folder apache ends the request with a connection reset
by peer.
[2009-07-02 15:18:33] cs at koch-aplsystems dot de
Description:
Apache 2.2 DocumentRoot is on a NTFS drive with a Mounted Volume (NTFS
Junction) Partition. All files the seem inaccessible to PHP 5.3.x (5.2.x
version do not show this problem)
Changing Apache DocumentRoot to a real directory on c: works around
the problem
#49042 [NEW]: Patch for fixing tests/basic/022.phpt and 023.phpt
From: mats dot lindh at gmail dot com Operating system: Any PHP version: 6SVN-2009-07-23 (SVN) PHP Bug Type: Unknown/Other Function Bug description: Patch for fixing tests/basic/022.phpt and 023.phpt Description: The cookie tests fails on the current svn build (Ubuntu 9.04, checked out last night). The problem seems to have been introduced after the merge of the UEXPECT section in revision 260316: http://svn.php.net/viewvc/php/php-src/trunk/tests/basic/023.phpt?r1=230273r2=260316 http://svn.php.net/viewvc/php/php-src/trunk/tests/basic/022.phpt?r1=230273r2=260316 Two of the values does not match the previous revisions, but the results from running the tests do (at least now). Patch (from svn diff) is available here: http://e-mats.org/resources/022-023.phpt.diff -- Edit bug report at http://bugs.php.net/?id=49042edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49042r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49042r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49042r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49042r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49042r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49042r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49042r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49042r=needscript Try newer version: http://bugs.php.net/fix.php?id=49042r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49042r=support Expected behavior: http://bugs.php.net/fix.php?id=49042r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49042r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49042r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49042r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49042r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49042r=dst IIS Stability: http://bugs.php.net/fix.php?id=49042r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49042r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49042r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49042r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49042r=mysqlcfg
#45384 [Com]: parse_ini_file will result in parse error with no trailing newline
ID: 45384
Comment by: mats dot lindh at gmail dot com
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Filesystem function related
Operating System: Ubuntu
PHP Version: 5.3CVS-2008-06-28 (CVS)
New Comment:
The fix to #45372 did not fix this issue, the problem is still in both
the PHP5_3 and HEAD branches.
Previous Comments:
[2008-06-29 00:50:26] [EMAIL PROTECTED]
$ echo -n foo.bar = baz test.ini
20:46 [EMAIL PROTECTED]:~
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file(test.ini));'
array(1) {
[foo.bar]=
string(4) baz
}
so the answer is, yes, a trailing space does not cause the error...if
this needs to be marked as a duplicate, whatever it takes to get this
working the same as php=5.2
[2008-06-28 11:22:11] [EMAIL PROTECTED]
This is probably also related to the re2c/YYFILL() scanner issues I
described in Bug #45372.
I assume it's because a variable length rule is matching (baz in your
example) when it hits EOF and YYFILL() causes a return/abort. This
(unexpected $end) is more likely to happen with ini parsing, etc. where
it doesn't usually happen with VALID code in a PHP script because the
last thing matched in a typical file is with a fixed length rule (e.g.
? or ;), and these things only happen with variable length matches
as I explained in the other bug, though they shouldn't with working
scanner code, IMO.
BTW, does putting a space or something other than a newline after baz
allow it to work? Any character that's not allowed in the rule matching
baz should also make it magically work. :-)
[2008-06-28 03:05:49] [EMAIL PROTECTED]
Description:
an ini file with no trailing newline will result in Parse error,
php5.3 only, 5.2 parses the file fine
Reproduce code:
---
$ echo -n foo.bar = baz test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file(test.ini));'
Expected result:
array(1) {
[foo.bar]=
string(3) baz
}
Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
in Command line code on line 1
Call Stack:
0.0003 312916 1. {main}() Command line code:0
0.0128 312936 2. parse_ini_file() Command line code:1
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=45384edit=1
