[PHP-BUG] Bug #61526 [NEW]: is_subclass_of(string, string, false) always returns false
From:
Operating system: Debian
PHP version: 5.3.10
Package: Class/Object related
Bug Type: Bug
Bug description:is_subclass_of(string, string, false) always returns false
Description:
According to the documentation (
http://php.net/manual/en/function.is-subclass-of.php ) the third parameter
of is_subclass_of decides "Whether to call autoloader if the class doesn't
exist."
That means that is_subclass_of('class1', 'class2', false) should
- return true if class1 is loaded and a subclass of class2
- return false if class1 is loaded but not a subclass of class2
- return false if class1 is not loaded
What actually happens is that it always returns false, no matter what. The
naming of the parameter - "$allow_string" - suggests this is somewhat
intentional, but it is a completely unintuitive and unhelpful behavior,
which makes the option completely useless: is_subclass_of with
$allow_string set to false becomes worthless if the first argument is a
string, and if it is an object, the third parameter is pointless again as
the class must have been loaded already.
Test script:
---
class Super {}
class Sub extends Super {}
var_dump(is_subclass_of('Sub', 'Super')); // true
var_dump(is_subclass_of('Sub', 'Super'), false); // should be true but
false
--
Edit bug report at https://bugs.php.net/bug.php?id=61526&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61526&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61526&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61526&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61526&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61526&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61526&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61526&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61526&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61526&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61526&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61526&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61526&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61526&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61526&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61526&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61526&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61526&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61526&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61526&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61526&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61526&r=mysqlcfg
[PHP-BUG] Bug #61527 [NEW]: ArrayIterator created from empty ArrayObject gives misleading notice on next()
From: Operating system: Debian PHP version: 5.3.10 Package: SPL related Bug Type: Bug Bug description:ArrayIterator created from empty ArrayObject gives misleading notice on next() Description: When trying to iterate the ArrayIterator of an empty ArrayObject, it throws a very misleading notice complaining about how the array was modified. In a complicated system, this will likely lead to a long wild goose chase of trying to find all the possible places where the object could have been accessed through some other iterator, when in reality the error is of a completely different nature. Test script: --- error_reporting(E_ALL); $ao = new ArrayObject(array()); $ai = $ao->getIterator(); $ai->next(); Expected result: $ai->next() returns null; no errors. (Or maybe a notice saying you reached the end of the array.) Actual result: -- $ai->next() returns null and throws a notice saying "ArrayIterator::next(): Array was modified outside object and internal position is no longer valid". -- Edit bug report at https://bugs.php.net/bug.php?id=61527&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61527&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61527&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61527&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61527&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61527&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61527&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61527&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61527&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61527&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61527&r=support Expected behavior: https://bugs.php.net/fix.php?id=61527&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61527&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61527&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61527&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61527&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61527&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61527&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61527&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61527&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61527&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61527&r=mysqlcfg
[PHP-BUG] Bug #54316 [NEW]: DateTime::createFromFormat does not handle trailing '|' correctly
From:
Operating system: Windows XP, Debian 2.6
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::createFromFormat does not handle trailing '|'
correctly
Description:
---
>From manual page: http://www.php.net/datetime.createfromformat
---
According to the documentation:
"""
| - Resets all fields (year, month, day, hour, minute, second, fraction and
timzone information) to the Unix Epoch if they have not been parsed yet
Y-m-d| will set the year, month and day to the information found in the
string to parse, and sets the hour, minute and second to 0.
"""
Actually, it fails to parse the date (but works correctly when | is not at
the end of the string).
Tested on PHP 5.3.2/Win XP and PHP 5.3.5/Debian. Can't test on 5.3.6 right
now as windows.php.net seems unavailable.
Test script:
---
var_dump(DateTime::createFromFormat('Y-m-d|', '2011-02-02'));
$errors = DateTime::getLastErrors();
var_dump($errors['errors']);
Expected result:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2011-02-02 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(15) "Europe/Budapest"
}
array(0) {
}
Actual result:
--
bool(false)
array(1) {
[10]=>
string(12) "Data missing"
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54316&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54316&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54316&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54316&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54316&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54316&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54316&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54316&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54316&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54316&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54316&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54316&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54316&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54316&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54316&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54316&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54316&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54316&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54316&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54316&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54316&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54316&r=mysqlcfg
Bug #12127 [Com]: Function fgetcsv() lost some letters
Edit report at https://bugs.php.net/bug.php?id=12127&edit=1 ID: 12127 Comment by: gtisza at gmail dot com Reported by:bitlz at mail dot ru Summary:Function fgetcsv() lost some letters Status: No Feedback Type: Bug Package:Filesystem function related Operating System: Windows 2000 Professional PHP Version:4.3.1 Block user comment: N Private report: N New Comment: Duplicate of bug 45356? Previous Comments: [2008-05-11 10:37:48] pienkowskip at gmail dot com I found out that locale in shell interpreter is 'pl_PL.UTF-8', but my Apache is using 'C' locale. I added to script: setlocale(LC_ALL, 'pl_PL.UTF-8'); and I has no problems with fgetcsv(). I think it should be fixed, because csv standard doesn't mention about locales or encodings - csv is rather binary than textual. [2008-05-11 10:21:51] pienkowskip at gmail dot com it's very strange that when I run script by shell interpreter it's works properly, but when my Apache runs it there is a problem (mentioned above) [2008-05-01 15:26:29] steve at google dot com confirming on PHP 5.2.0-8 Csv file line:- 1,Alert Status,État de l'alerte fgetcsv ignores the É It only happens if É is right after the delimiter , Only way I got around this was to save the file as UTF8 as mention in the earlier comment. Didnt work even with setlocale(LC_ALL,'fr_FR.ISO-8859-1') [2007-06-01 12:58:59] laus at tinevej dot dk I got the same problem in php-5.2.2 with danish special letters (ÆØÅ) when it is saved in iso-8859-1. But if i save the csv files as utf-8 the problem disappears. [2006-11-24 09:32:47] info at netangels dot ru Guys The problem still occurs even in PHP 5.2.0 and PHP 5.1.x as well as in 5.0.x but we've found a workaround. If csv-file is in russian encoding (cp1251) then php-script should do: setlocale(LC_ALL, "ru_RU"); BEFORE call fgetcsv() if current locale is not ru_RU. If locale is ru_RU already, it works well on all versions of php from 4.3.x up to the latest 5.2.0 without requiring setlocale() 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=12127 -- Edit this bug report at https://bugs.php.net/bug.php?id=12127&edit=1
Bug #45356 [Com]: fgetcsv() � symbol stripped if first char in cell
Edit report at https://bugs.php.net/bug.php?id=45356&edit=1
ID: 45356
Comment by: gtisza at gmail dot com
Reported by:al at txtlocal dot com
Summary:fgetcsv() £ symbol stripped if first char in cell
Status: No Feedback
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
fgetcsv() seems to throw the first character away if it is invalid in the
current locale, but ignores invalid characters which are not at the beginning
of a cell. This code reproduces the problem in PHP 5.3.6:
I agree with the commenter in bug 12127 that a CSV function should not mess
with encodings in the first place, just copy the content byte-by-byte.
Previous Comments:
[2008-09-08 22:06:42] sfschiller at gmail dot com
based on [mk at kurznet dot com]
a change of the locale information helps.
setlocale(LC_ALL,'de_DE.8859-1');
setting the locale information to a unicode or UTF locale names will lose the
first letters.
[2008-09-08 19:04:43] mk at kurznet dot com
if have the same problem with php 5.2.6
the csv file looks like this: äüö123äüö;auo123äüö
$handle = fopen($path."Mappe3.csv","r");
while ($data = fgetcsv ($handle, 4096, ";")) {
print_r($data);
}
fclose ($handle);
Array
(
[0] => 123äüö
[1] => auo123äüö
)
with PHP 5.2.5 and 4.4.8 everything is ok ?
is this a bug or a feature ?
[2008-07-27 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-07-19 17:50:18] m...@php.net
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.
I'm unable to reproduce it with a simple scripts neither with 5.2.6 nor with
5.3.0-dev.
[2008-06-25 18:08:31] al at txtlocal dot com
If you have csv file:
name,price
James,£150
fgetcsv() will remove the £.
All other chars seem to be fine.
I have searched forums for an answer to this and there are a few people
reporting the same - but no definitive answer.
In addition - this is only if the £ character in the first char in a
"cell". This would work fine:
name,price
James,1£50
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=45356
--
Edit this bug report at https://bugs.php.net/bug.php?id=45356&edit=1
[PHP-BUG] Bug #55507 [NEW]: fgetcsv() handles invalid characters inconsistently
From: Operating system: Linux PHP version: Irrelevant Package: Filesystem function related Bug Type: Bug Bug description:fgetcsv() handles invalid characters inconsistently Description: fgetcsv() throws away the first character of a field if it is invalid in the current locale, but ignores invalid characters which are not at the beginning of a field. The inconsistent behavior makes it hard to locate the source of the bug; it should either throw all invalid characters away, or none of them (IMO the second is much better). (This is a duplicate of bug 45356, but that one has been closed as "no feedback", and apparently mere mortals are not allowed to reopen it, even if they do provide the feedback...) Test script: --- -- Edit bug report at https://bugs.php.net/bug.php?id=55507&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55507&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55507&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55507&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55507&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55507&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55507&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55507&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55507&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55507&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55507&r=support Expected behavior: https://bugs.php.net/fix.php?id=55507&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55507&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55507&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55507&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55507&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55507&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55507&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55507&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55507&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55507&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55507&r=mysqlcfg
Req #46367 [Com]: fputcsv does not add the correct newline character on Windows
Edit report at https://bugs.php.net/bug.php?id=46367&edit=1
ID: 46367
Comment by: gtisza at gmail dot com
Reported by:jmer...@php.net
Summary:fputcsv does not add the correct newline character
on Windows
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Windows XP
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
See https://bugs.php.net/bug.php?id=42357 (add optional parameter for line
ending to fputcsv).
Previous Comments:
[2010-03-10 20:41:53] johan...@php.net
Applying the "correct" patch means that the resulting file is system dependent
and might break what current users expect. Probably this needs to be configured
(additional parameter?)
[2010-03-10 19:50:50] m_rayman at bigfoot dot com
For such a simple bug, this should have been solved the same week it was
brought to attention... The correct and tested patch is even included!
[2009-07-17 11:41:41] chris dot tatedavies at inflightproductions dot com
How long does the voting last? I need to know if this is going to be fixed. Or
if it has been already. I've looked through the changelog to no avail. Its been
over 8 months since the original report.
Thanks, Chris
[2008-11-06 13:49:51] jmer...@php.net
Updated earlier patch:
Index: file.c
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.530
diff -u -r1.530 file.c
--- file.c 21 Oct 2008 22:06:48 - 1.530
+++ file.c 22 Oct 2008 21:21:42 -
@@ -2104,7 +2104,7 @@
}
}
- smart_str_appendc(&csvline, '\n');
+ smart_str_appendl(&csvline, PHP_EOL, sizeof(PHP_EOL));
smart_str_0(&csvline);
ret = php_stream_write(stream, csvline.c, csvline.len);
Also below is a test case for this bug. Should fail currently on Windows.
--TEST--
Bug #46367 - fputcsv does not add the correct newline character on Windows
--FILE--
--EXPECT--
bool(true)
Done
[2008-10-22 17:00:52] jmer...@php.net
Description:
Per the documentation for the fputcsv() function, it adds a newline to the end
of the csv string it returns. However, it is hardcoded to be '\n' ( default for
unix newline ), while Windows uses \r\n. PHP should do this as well.
Below is a patch to fix this issue; it uses the constant PHP_EOL to get the
correct newline to use on the current platform:
Index: php-src/ext/standard/file.c
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.530
diff -r1.530 file.c
2107c2107
< smart_str_appendc(&csvline, '\n');
---
> smart_str_appendc(&csvline, PHP_EOL);
Reproduce code:
---
$array1 = array("a","b","c");
$array2 = array("d","e","f");
echo fputcsv($array1).fputcsv($array2);
Expected result:
"a","b","c"
"d","e","f"
Actual result:
--
"a","b","c""d","e","f"
--
Edit this bug report at https://bugs.php.net/bug.php?id=46367&edit=1
Bug #54556 [Com]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Comment by: gtisza at gmail dot com Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: The same happens with every non-string scalar value, not just null: This is a major problem as lots of data access functions return null or false if the key is not found (memcached for example, or may active record libraries), so this bug can easily lead to unexpected behavior. In unfortunate cases (e.g. trying to load a usergroup blacklist from database) it might even lead to authentication bypass vulnerabilities and other severe security issues. Previous Comments: [2011-09-14 13:53:51] dmi...@php.net I've added a bit better patch (for trunk), but I'm not sure we need it. At least it "breaks" about 30 tests. [2011-09-14 13:51:04] dmi...@php.net The following patch has been added/updated: Patch Name: wrong-array-access.diff Revision: 1316008264 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=wrong-array-access.diff&revision=1316008264 [2011-09-14 07:28:36] larue...@php.net dmitry, plz look at this, thanks [2011-07-26 11:12:22] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311678742 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311678742 [2011-07-25 12:10:52] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311595852 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=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556&edit=1
