[PHP-BUG] Req #63617 [NEW]: Make file_exists() case insensitive
From: soapergem at gmail dot com Operating system: *nix PHP version: Irrelevant Package: Filesystem function related Bug Type: Feature/Change Request Bug description:Make file_exists() case insensitive Description: Currently file_exists() is case insensitive on Windows, but not on *nix platforms. This makes it difficult to migrate from Windows back to *nix. Forcing file_exists() to always be case insensitive would be of great benefit in these scenarios. I'm not sure what the engineering behind it would involve, but I thought I'd ask! Test script: --- ?php $dir = dirname(__FILE__) . DIRECTORY_SEPARATOR; var_dump(file_exists($dir . 'cAsE_mAtTeRs.php')); ? Expected result: true Actual result: -- false -- Edit bug report at https://bugs.php.net/bug.php?id=63617edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63617r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63617r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63617r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63617r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63617r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63617r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63617r=needscript Try newer version: https://bugs.php.net/fix.php?id=63617r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63617r=support Expected behavior: https://bugs.php.net/fix.php?id=63617r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63617r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63617r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63617r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63617r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63617r=dst IIS Stability: https://bugs.php.net/fix.php?id=63617r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63617r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63617r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63617r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63617r=mysqlcfg
Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't
Edit report at https://bugs.php.net/bug.php?id=62861edit=1 ID: 62861 User updated by:soapergem at gmail dot com Reported by:soapergem at gmail dot com Summary:htmlentities returns empty string when it shouldn't Status: Not a bug Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.4.6 Block user comment: N Private report: N New Comment: Yes, your assumptions about what I was meaning to say were correct. I really meant ANSI, which you know as CP-1252. But there is definitely still a bug with this. I just followed your instructions by saving my test script specifically in the UTF-8 encoding hoping that, as you said, all my problems will go away. They didn't. My test script is exactly the same one that I have listed on this bug report. I saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting an empty string -- which is progress. But now I am getting the following output: copy; This is definitely NOT the expected result here. It did finally convert the copyright symbol, but it prepended not one, not two, but THREE junk characters in front of it. This is even worse than before. If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the idea of converting everything to Unicode deemed too ambitious? I've already spent far too much time dealing with this than is practical, as I'm sure you have much better things to do, as well. It just seems to me that you guys had a wonderful hammer -- a wonderful tool for the job -- and you went and broke off the hammer head for no apparent reason. If I might make a humble suggestion, why not let htmlentities() default to whatever the default_charset option is in php.ini? Right now you can only do that by explicitly passing an empty string as the third parameter to htmlentities, which is very messy and counterintuitive. Shouldn't the default_charset actually be, you know, the _default character set_? Previous Comments: [2012-08-19 05:22:03] ras...@php.net I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows internally is actually UTF-16 but there is a library call named isTextUnicode() which most apps use to determine which encoding something is in and it tends towards CP-1252 if it can't figure it out, so I assume that is what you mean when you say everyone saves things in ISO-8859-1 on Windows. Every editor I know of has a very simple encoding setting to force the editor to a specific encoding. Set it to UTF-8 and all your problems will go away. Note also that CP- 1252 is not used in most of the world, so this assertion that most pages are saved in ISO-8859-1 is obviously not true. Regardless, this is not something that will be reverted. CP-1252 is disappearing and I think you will find much less of it in Windows8 as it really doesn't play well with HTML5. [2012-08-19 05:02:02] soapergem at gmail dot com With respect, the 72% figure you cited is misleading at best. The character encoding listed in the HTML gives no indication of what encoding the files were actually saved in. All it is is a meta tag in that head that says UTF-8. I would suspect the vast majority of those files are still saved in ISO-8859-1, though. My prediction is that you're going to get A LOT of complaints over the switch -- especially from Windows users, who almost always save things in ISO-8859-1, since that is the default encoding in Windows. With PHP on Windows ever growing, fighting the Windows users is just shooting yourself in the foot. [2012-08-19 04:38:50] ras...@php.net UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in ISO-8859-1 is character code (in hex) A9. In UTF-8 the copyright symbol is represented by two bytes, C2A9. The world has gone UTF-8. If your editor is in UTF-8 mode and you enter/paste a copyright symbol and pass it to htmlentities() you will get copy; back. So rather than change the code to hardcode ISO-8859-1 you should convert your datasources to UTF-8. Most of them are probably already UTF-8 which means that your current code was likely not handling these correctly since it assumed ISO-8859-1 before. For some perspetive: http://w3techs.com/technologies/overview/character_encoding/all which shows that 72% of the top-million sites on the Web are using UTF-8. And this number is growing. [2012-08-19 04:14:03] soapergem at gmail dot com Description: Doesn't UTF-8 include basic ASCII characters, too? Right now when I try to encode the copyright symbol (©) using htmlentities (it should encode
Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't
Edit report at https://bugs.php.net/bug.php?id=62861edit=1
ID: 62861
User updated by:soapergem at gmail dot com
Reported by:soapergem at gmail dot com
Summary:htmlentities returns empty string when it shouldn't
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Windows
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
There is no option to save without the BOM in Windows Notepad. Nor is there an
option to save with/without the BOM in many other Windows editors. It is
automatically added to the file and there is nothing I can do about that --
short of writing a script to programmatically go through all my other scripts
with fopen(), remove the first three characters, and then re-save.
That is NOT a practical option. PHP should be handling this.
As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need
to
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts
of ANYONE who uses htmlentities() on a Windows server. Please take my
suggestion
about using the default_charset to heart. That would finally resolve this issue.
Previous Comments:
[2012-08-19 13:59:09] ni...@php.net
Save your document as UTF-8 *without* BOM. The  is just what the UTF-8
Byte Order Mark (BOM) looks like when it is output (which is probably something
you don't want, so save the file without it).
[2012-08-19 13:49:39] ras...@php.net
From my command line:
php echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;
it works fine. If you are actually providing the correct UTF-8 char it will
work
fine. You can verify that by doing this:
php $a = chr(0xC2).chr(0xA9);
php echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;
Here I am explicitly passing C2A9 in and I get copy; back out.
So I have no idea what your Windows Notepad is doing. Look at the output with a
hex editor and see what it is converting that copyright character to.
[2012-08-19 13:30:07] soapergem at gmail dot com
Yes, your assumptions about what I was meaning to say were correct. I really
meant ANSI, which you know as CP-1252.
But there is definitely still a bug with this. I just followed your
instructions
by saving my test script specifically in the UTF-8 encoding hoping that, as
you said, all my problems will go away.
They didn't.
My test script is exactly the same one that I have listed on this bug report. I
saved it in Windows Notepad, using the UTF-8 encoding. I am no longer getting
an empty string -- which is progress. But now I am getting the following output:
copy;
This is definitely NOT the expected result here. It did finally convert the
copyright symbol, but it prepended not one, not two, but THREE junk characters
in front of it. This is even worse than before.
If I'm not mistaken, wasn't the whole reason PHP6 was abandoned because the
idea
of converting everything to Unicode deemed too ambitious? I've already spent
far
too much time dealing with this than is practical, as I'm sure you have much
better things to do, as well. It just seems to me that you guys had a wonderful
hammer -- a wonderful tool for the job -- and you went and broke off the hammer
head for no apparent reason.
If I might make a humble suggestion, why not let htmlentities() default to
whatever the default_charset option is in php.ini? Right now you can only do
that by explicitly passing an empty string as the third parameter to
htmlentities, which is very messy and counterintuitive. Shouldn't the
default_charset actually be, you know, the _default character set_?
[2012-08-19 05:22:03] ras...@php.net
I think you are confusing CP-1252 with ISO-8859-1. And the default on Windows
internally is actually UTF-16 but there is a library call named isTextUnicode()
which most apps use to determine which encoding something is in and it tends
towards CP-1252 if it can't figure it out, so I assume that is what you mean
when you say everyone saves things in ISO-8859-1 on Windows. Every editor I
know
of has a very simple encoding setting to force the editor to a specific
encoding. Set it to UTF-8 and all your problems will go away. Note also that CP-
1252 is not used in most of the world, so this assertion that most pages are
saved in ISO-8859-1 is obviously not true. Regardless, this is not something
that will be reverted. CP-1252 is disappearing and I think you will find much
less of it in Windows8 as it really doesn't play well with HTML5.
[2012-08-19 05:02:02
Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't
Edit report at https://bugs.php.net/bug.php?id=62861edit=1
ID: 62861
User updated by:soapergem at gmail dot com
Reported by:soapergem at gmail dot com
Summary:htmlentities returns empty string when it shouldn't
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Windows
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
I am aware that Notepad is not a suitable editor for development. It is just
the
de facto basic editor in Windows. If something doesn't work in Notepad,
you're
usually in trouble.
I use an editor called EditPlus, which is a very good editor. The older version
which I have used does not have support for removing the BOM, but I see the
newer version does, so I will have to upgrade.
But I would really appreciate it if you could address my suggestion about using
the default_charset defined in php.ini automatically. Right now having to call
htmlentities($string, ENT_COMPAT | ENT_HTML401, ) seems very
counter-intuitive
to invoke what should be the default.
Previous Comments:
[2012-08-19 14:27:31] ras...@php.net
Every real editor can do that. Windows Notepad is not a real editor. Notepad++
(which is free and much much better than Notepad), Notepad2, Textmate, Vim,
Jedit, Ultraedit, Emacs, SourceEdit can all do this.
[2012-08-19 14:27:07] ni...@php.net
Windows Notepad does not support this because Notepad is not a suitable editor
for development. All development-oriented texteditors and IDEs support saving
files without BOM.
One commonly used text editor for Windows is Notepad++ (in case you don't want
to use a full-blown IDE).
[2012-08-19 14:11:43] soapergem at gmail dot com
There is no option to save without the BOM in Windows Notepad. Nor is there an
option to save with/without the BOM in many other Windows editors. It is
automatically added to the file and there is nothing I can do about that --
short of writing a script to programmatically go through all my other scripts
with fopen(), remove the first three characters, and then re-save.
That is NOT a practical option. PHP should be handling this.
As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need
to
stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts
of ANYONE who uses htmlentities() on a Windows server. Please take my
suggestion
about using the default_charset to heart. That would finally resolve this issue.
[2012-08-19 13:59:09] ni...@php.net
Save your document as UTF-8 *without* BOM. The  is just what the UTF-8
Byte Order Mark (BOM) looks like when it is output (which is probably something
you don't want, so save the file without it).
[2012-08-19 13:49:39] ras...@php.net
From my command line:
php echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;
it works fine. If you are actually providing the correct UTF-8 char it will
work
fine. You can verify that by doing this:
php $a = chr(0xC2).chr(0xA9);
php echo htmlentities($a, ENT_COMPAT | ENT_HTML401, 'UTF-8');
copy;
Here I am explicitly passing C2A9 in and I get copy; back out.
So I have no idea what your Windows Notepad is doing. Look at the output with a
hex editor and see what it is converting that copyright character to.
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=62861
--
Edit this bug report at https://bugs.php.net/bug.php?id=62861edit=1
Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't
Edit report at https://bugs.php.net/bug.php?id=62861edit=1 ID: 62861 User updated by:soapergem at gmail dot com Reported by:soapergem at gmail dot com Summary:htmlentities returns empty string when it shouldn't Status: Not a bug Type: Bug Package:*General Issues Operating System: Windows PHP Version:5.4.6 Block user comment: N Private report: N New Comment: That makes sense. In that case, could I submit a feature request to add a config option to php.ini called default_encoding? By default (or if omitted) it would be UTF-8, of course. This would allow users to change it one place (or change it via ini_set) to set the default for the htmlspecialchars family of functions, rather than having to grep all the code to change each function call. Previous Comments: [2012-08-19 14:57:05] ni...@php.net The default_charset sets default charset for the Content-Type header. It doesn't really have anything to do with the htmlspecialchars() family of functions. The '' encoding is some sort of magic charset detection algorithm that may or may not guess correctly. The docs explicitly state that you should not use it. [2012-08-19 14:31:20] soapergem at gmail dot com I am aware that Notepad is not a suitable editor for development. It is just the de facto basic editor in Windows. If something doesn't work in Notepad, you're usually in trouble. I use an editor called EditPlus, which is a very good editor. The older version which I have used does not have support for removing the BOM, but I see the newer version does, so I will have to upgrade. But I would really appreciate it if you could address my suggestion about using the default_charset defined in php.ini automatically. Right now having to call htmlentities($string, ENT_COMPAT | ENT_HTML401, ) seems very counter-intuitive to invoke what should be the default. [2012-08-19 14:27:31] ras...@php.net Every real editor can do that. Windows Notepad is not a real editor. Notepad++ (which is free and much much better than Notepad), Notepad2, Textmate, Vim, Jedit, Ultraedit, Emacs, SourceEdit can all do this. [2012-08-19 14:27:07] ni...@php.net Windows Notepad does not support this because Notepad is not a suitable editor for development. All development-oriented texteditors and IDEs support saving files without BOM. One commonly used text editor for Windows is Notepad++ (in case you don't want to use a full-blown IDE). [2012-08-19 14:11:43] soapergem at gmail dot com There is no option to save without the BOM in Windows Notepad. Nor is there an option to save with/without the BOM in many other Windows editors. It is automatically added to the file and there is nothing I can do about that -- short of writing a script to programmatically go through all my other scripts with fopen(), remove the first three characters, and then re-save. That is NOT a practical option. PHP should be handling this. As it stands, PHP 5.4 is completely unusable. Until you guys fix this, I need to stick with 5.3, because 5.4 will break all of my scripts -- and all the scripts of ANYONE who uses htmlentities() on a Windows server. Please take my suggestion about using the default_charset to heart. That would finally resolve this issue. 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=62861 -- Edit this bug report at https://bugs.php.net/bug.php?id=62861edit=1
[PHP-BUG] Bug #62861 [NEW]: htmlentities returns empty string when it shouldn't
From: soapergem at gmail dot com
Operating system: Windows
PHP version: 5.4.6
Package: *General Issues
Bug Type: Bug
Bug description:htmlentities returns empty string when it shouldn't
Description:
Doesn't UTF-8 include basic ASCII characters, too? Right now when I try to
encode the copyright symbol (©) using htmlentities (it should encode to
copy;), it doesn't work. I discovered this since the default encoding for
htmlentities() was switched from ISO-8859-1 to UTF-8 in version 5.4.
I have plenty of places where I rely on basic symbols, such as the
copyright symbol, being encoded properly with htmlentities(). Having to go
in and change all the instances of htmlentities($string) to
htmlentities($string, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1') is not
practical (there are MANY). And with the whole output of the function being
blank, it just makes my scripts completely unusable now.
Help!
Test script:
---
?php
echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
?
Expected result:
copy;
Actual result:
--
(Nothing - an empty string)
--
Edit bug report at https://bugs.php.net/bug.php?id=62861edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62861r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62861r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62861r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62861r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62861r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62861r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62861r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62861r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62861r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62861r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62861r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62861r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62861r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62861r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62861r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62861r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62861r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62861r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62861r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62861r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62861r=mysqlcfg
Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't
Edit report at https://bugs.php.net/bug.php?id=62861edit=1
ID: 62861
User updated by:soapergem at gmail dot com
Reported by:soapergem at gmail dot com
Summary:htmlentities returns empty string when it shouldn't
Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Windows
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
With respect, the 72% figure you cited is misleading at best. The character
encoding listed in the HTML gives no indication of what encoding the files were
actually saved in. All it is is a meta tag in that head that says UTF-8. I
would suspect the vast majority of those files are still saved in ISO-8859-1,
though.
My prediction is that you're going to get A LOT of complaints over the switch
--
especially from Windows users, who almost always save things in ISO-8859-1,
since that is the default encoding in Windows. With PHP on Windows ever
growing,
fighting the Windows users is just shooting yourself in the foot.
Previous Comments:
[2012-08-19 04:38:50] ras...@php.net
UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in
ISO-8859-1 is character code (in hex) A9. In UTF-8 the copyright symbol is
represented by two bytes, C2A9. The world has gone UTF-8. If your editor is
in UTF-8 mode and you enter/paste a copyright symbol and pass it to
htmlentities() you will get copy; back. So rather than change the code to
hardcode ISO-8859-1 you should convert your datasources to UTF-8. Most of them
are probably already UTF-8 which means that your current code was likely not
handling these correctly since it assumed ISO-8859-1 before.
For some perspetive:
http://w3techs.com/technologies/overview/character_encoding/all
which shows that 72% of the top-million sites on the Web are using UTF-8. And
this number is growing.
[2012-08-19 04:14:03] soapergem at gmail dot com
Description:
Doesn't UTF-8 include basic ASCII characters, too? Right now when I try to
encode the copyright symbol (©) using htmlentities (it should encode to
copy;), it doesn't work. I discovered this since the default encoding for
htmlentities() was switched from ISO-8859-1 to UTF-8 in version 5.4.
I have plenty of places where I rely on basic symbols, such as the copyright
symbol, being encoded properly with htmlentities(). Having to go in and change
all the instances of htmlentities($string) to htmlentities($string, ENT_COMPAT
| ENT_HTML401, 'ISO-8859-1') is not practical (there are MANY). And with the
whole output of the function being blank, it just makes my scripts completely
unusable now.
Help!
Test script:
---
?php
echo htmlentities('©', ENT_COMPAT | ENT_HTML401, 'UTF-8');
?
Expected result:
copy;
Actual result:
--
(Nothing - an empty string)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62861edit=1
#50296 [NEW]: Automatically translate self in method_exists
From: soapergem at gmail dot com
Operating system: Windows XP
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: Automatically translate self in method_exists
Description:
In reference to bug #50289:
If I call method_exists(self, method) from within a class, it
should automatically translate self to the classname. Right now the
behavior is not obvious; the behavior does not adhere to the KISS
principle.
1. method_exists already can check for static methods.
2. self can already automatically translate to the current class
name, for instance in call_user_func.
3. The most logical, simple and obvious expectation is that if you
combine these two--you call method_exists with self--that it will
automatically translate self to the current class name, and check
for the method. Currently it does not. The current behavior is
counterintuitive and confusing.
Making this change is not dangerous. Making this change will not cause
any backwards-compatibility issues.
1. self is a reserved word. You cannot declare a class named self-
-this will issue a fatal error. So there is no possibility of any
ambiguity. You cannot confuse self with any other class, because no
other class can be named self.
It does not make sense to have self work in some contexts but not in
others. It would be better if it were consistent.
Reproduce code:
---
?php
class Test
{
public static function check()
{
var_dump(method_exists(self, method));
}
public static function method() { }
}
Test::check();
?
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=50296edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50296r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50296r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50296r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50296r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50296r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50296r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50296r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50296r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50296r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50296r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50296r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50296r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50296r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50296r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50296r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50296r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50296r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50296r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50296r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50296r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50296r=mysqlcfg
#50289 [NEW]: method_exists doesn't work on self
From: soapergem at gmail dot com
Operating system: Windows XP
PHP version: 5.3.1
PHP Bug Type: Class/Object related
Bug description: method_exists doesn't work on self
Description:
method_exists doesn't work if you pass in a callback with a reference to
self. Yet call_user_func *does* work if you pass in a callback with a
reference to self. This is inconsistent and probably not intentional.
Reproduce code:
---
?php
class Test
{
public static function check_method()
{
var_dump(method_exists('self', 'output'));
}
public static function run_method()
{
call_user_func(array('self', 'output'));
}
public static function output()
{
echo 'this works';
}
}
Test::check_method();
Test::run_method();
?
Expected result:
bool(true)
this works
Actual result:
--
bool(false)
this works
--
Edit bug report at http://bugs.php.net/?id=50289edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50289r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50289r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50289r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50289r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50289r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50289r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50289r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50289r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50289r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50289r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50289r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50289r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50289r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50289r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50289r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50289r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50289r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50289r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50289r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50289r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50289r=mysqlcfg
#49824 [NEW]: Change the behavior of array_fill ever so slightly
From: soapergem at gmail dot com
Operating system: WinXP
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: Change the behavior of array_fill ever so slightly
Description:
Right now array_fill() returns false and throws an E_WARNING if its second
parameter ($num) is less than 1. This is counter-intuitive. As you know,
the purpose of array_fill is to create an array with the given number of
elements, all preset to one value. The restriction SHOULD be that $num
cannot be less than 0, rather than saying it cannot be less than 1.
Why? Because an array of zero-length is a perfectly valid thing in PHP. I
ran into a scenario where I was using array fill and $num was a dynamic
value. I would have never expected that PHP would actually throw a warning
if I told it to create an empty array. I had to write a wrapper function to
accommodate, which is stupid. Just allow me to create an empty array like
any reasonable person would expect!
Reproduce code:
---
?php
$array1 = array_fill(0, -1, 1);
$array2 = array_fill(0, 0, 1);
$array3 = array_fill(0, 1, 1);
var_dump($array1);
var_dump($array2);
var_dump($array3);
?
Expected result:
bool(false)
array(0) {
}
array(1) {
[0]=
int(1)
}
PHP Warning: array_fill(): Number of elements must be nonnegative in
C:\test.php on line 3
Actual result:
--
bool(false)
bool(false)
array(1) {
[0]=
int(1)
}
PHP Warning: array_fill(): Number of elements must be positive in
C:\test.php on line 3
PHP Warning: array_fill(): Number of elements must be positive in
C:\test.php on line 4
--
Edit bug report at http://bugs.php.net/?id=49824edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49824r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49824r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49824r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49824r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49824r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49824r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49824r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49824r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49824r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49824r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49824r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49824r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49824r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49824r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49824r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49824r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49824r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49824r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49824r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49824r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49824r=mysqlcfg
#49350 [Bgs]: fgets reads the UTF-8 Byte Order Mark literally
ID: 49350
User updated by: soapergem at gmail dot com
Reported By: soapergem at gmail dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
But generally speaking this isn't desired behavior from the user
standpoint. When you open a file in Notepad that has this character at
the front, you never see it. I never knew it was there until trying to
read it raw through PHP, since it is clearly not intended to be part of
the content, but instead part of the file meta-data.
It would be unwise not to expect that Unicode will eventually become
the standard. And currently the burden is on the PHP user to account for
it, when I think it should be a language feature. So I suggest doing
something like adding a letter to the mode of fopen(), for instance
something like this:
$fp = fopen('utf8_text_file.txt', 'ru');
The u would indicate that the file *may* be encoded in UTF-8, and if
so, throw out the BOM at the front. This would mean that fseek'ing to 0
would effectively start just after the BOM (if present), and the file
would be initialized to this seek position. This would provide backwards
compatibility, since you would have to change the fopen() mode for it to
detect the BOM. And it'd make things for PHP users like myself a lot
easier.
Just a thought.
Previous Comments:
[2009-08-25 06:44:45] j...@php.net
Of course it does. If it didn't, it would be broken.
[2009-08-24 22:31:38] soapergem at gmail dot com
Description:
When text files are saved with UTF-8 encoding, a few characters are
saved at the front called the Byte Order Mark (read more about it on
Wikipedia). They are supposed to remain hidden and just be used as
meta-data to indicate that the file is saved with UTF-8 formatting.
Their hex values are EF BB BF, which is represented in ASCII by .
The trouble is that when you read in a UTF-8 text file with either
fgets or fgetcsv, PHP misinterprets the BOM as literal text and includes
it with all the other text.
Reproduce code:
---
?php
if ( $fp = fopen('ut8_text_file.txt') ) {
echo fgets($fp);
fclose($fp);
}
?
Expected result:
Whatever text is saved on the first line of the text file.
Actual result:
--
Whatever text is saved on the first line of the text file.
--
Edit this bug report at http://bugs.php.net/?id=49350edit=1
#49350 [NEW]: fgets reads the UTF-8 Byte Order Mark literally
From: soapergem at gmail dot com
Operating system: Windows XP
PHP version: 5.3.0
PHP Bug Type: Filesystem function related
Bug description: fgets reads the UTF-8 Byte Order Mark literally
Description:
When text files are saved with UTF-8 encoding, a few characters are saved
at the front called the Byte Order Mark (read more about it on
Wikipedia). They are supposed to remain hidden and just be used as
meta-data to indicate that the file is saved with UTF-8 formatting. Their
hex values are EF BB BF, which is represented in ASCII by .
The trouble is that when you read in a UTF-8 text file with either fgets
or fgetcsv, PHP misinterprets the BOM as literal text and includes it with
all the other text.
Reproduce code:
---
?php
if ( $fp = fopen('ut8_text_file.txt') ) {
echo fgets($fp);
fclose($fp);
}
?
Expected result:
Whatever text is saved on the first line of the text file.
Actual result:
--
Whatever text is saved on the first line of the text file.
--
Edit bug report at http://bugs.php.net/?id=49350edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49350r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49350r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49350r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49350r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49350r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49350r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49350r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49350r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49350r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49350r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49350r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49350r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49350r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49350r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49350r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49350r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49350r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49350r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49350r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49350r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49350r=mysqlcfg
#49011 [NEW]: Middle Endian date format only semi-recognized by strtotime
From: soapergem at gmail dot com
Operating system: Windows
PHP version: 5.3.0
PHP Bug Type: Date/time related
Bug description: Middle Endian date format only semi-recognized by strtotime
Description:
An extremely common date format in the USA is middle endian, which is
often expressed in one of two ways. Today's date (July 21, 2009) could be
expressed as either of the following:
1. 07/21/2009
2. 07-21-2009
Currently, if the first version (1) is passed into strtotime(), it
successfully parses the date. However, the second version (2) returns
FALSE.
Reproduce code:
---
?php
var_dump(strtotime('07/21/2009')); // good
var_dump(strtotime('07-21-2009')); // bad
?
Expected result:
int(1248152400)
int(1248152400)
Actual result:
--
int(1248152400)
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49011edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49011r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49011r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49011r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49011r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49011r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49011r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49011r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49011r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49011r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49011r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49011r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49011r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49011r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49011r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49011r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49011r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49011r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49011r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49011r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49011r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49011r=mysqlcfg
#48454 [NEW]: touch() does not modify accessed time in Windows
From: soapergem at gmail dot com Operating system: Windows XP PHP version: 5.2.9 PHP Bug Type: Filesystem function related Bug description: touch() does not modify accessed time in Windows Description: The touch() command does not actually modify the accessed time of a file on a Windows platform. After calling touch() on a file with an access time specified, the access time is set to the current time. Reproduce code: --- ?php $file = 'C:\\test.txt'; $mtime = filemtime($file); $atime = fileatime($file); $newtime = mktime(0, 0, 0, 1, 1, 2009); $result1 = touch($file, $mtime, $newtime); $result2 = ( $atime != fileatime($file) ); var_dump($result1); var_dump($result2); ? Expected result: On the first run, we should expect the file C:\test.txt to have an access time of January 1st, 2009, and this expected PHP output: bool(true) bool(true) Actual result: -- Instead, the file C:\test.txt will have an access time of whenever the script ran, and this is the PHP output we get: bool(true) bool(false) -- Edit bug report at http://bugs.php.net/?id=48454edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48454r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48454r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48454r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48454r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48454r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48454r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48454r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48454r=needscript Try newer version: http://bugs.php.net/fix.php?id=48454r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48454r=support Expected behavior: http://bugs.php.net/fix.php?id=48454r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48454r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48454r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48454r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48454r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48454r=dst IIS Stability: http://bugs.php.net/fix.php?id=48454r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48454r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48454r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48454r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48454r=mysqlcfg
#43452 [Com]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452
Comment by: soapergem at gmail dot com
Reported By: sean dot thorne at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X 10.4.11
PHP Version: 5.2CVS-2007-11-29 (CVS)
New Comment:
I also confirmed this. This is pretty serious, too! There are an
infinite number of examples in which you can reproduce it; here are a
few:
// expect 06-15-2008, get 06-22-2008
$date = strtotime('3 Sunday June 2008');
echo date('m-d-Y', $date);
// expect 07-08-2008, get 07-15-2008
$date = strtotime('2 Tuesday July 2008');
echo date('m-d-Y', $date);
// expect 08-22-2008, get 08-29-2008
$date = strtotime('4 Friday August 2008');
echo date('m-d-Y', $date);
// expect 09-29-2008, get 10-06-2008
$date = strtotime('5 Monday September 2008');
echo date('m-d-Y', $date);
// expect 10-01-2008, get 10-08-2008
$date = strtotime('1 Wednesday October 2008');
echo date('m-d-Y', $date);
Developers please take note: THIS IS A SERIOUS BUG! (and it's been
around for a long time)
Previous Comments:
[2008-04-02 14:06:23] billyt at claritytech dot com
We also wrote our own function that handles it. Although, it's purely
by random chance that we discovered the problem. It's not something we
would specifically have tested for. I wonder how many other people are
using it in production with no idea that it's a problem.
[2008-03-30 22:39:34] sean dot thorne at gmail dot com
I ended up writing a compensator for the problem, because it appears
that the PHP Dev crew has better things to do then clean up the code
base...
I kept it simple and grabbed what day was the the first of the month
and then found where Thursday would be in comparison and knew the third
thursday was just 3 times whatever the date of the first thursday.
[2008-03-30 22:21:21] billyt at claritytech dot com
This is still a problem with 5.2.6RC4-dev!!!
This is causing us serious issues ... any ideas???
[2007-11-29 15:39:52] sean dot thorne at gmail dot com
Description:
When asking strtotime for the 3rd thursday in a month and the first day
of that month is thursday, it ignores the first thursday. It then begins
to count after that first Thursday and returns the fourth Thursday.
Reproduce code:
---
$day = strtotime(3 Thursday Nov 2007);
echo date(m-d-Y, $day);
Expected result:
11-15-2007
Actual result:
--
11-22-2007
--
Edit this bug report at http://bugs.php.net/?id=43452edit=1
