Bug #61033 [Com]: __FUNCTION__ doesn't report correctly in alias trait methods
Edit report at https://bugs.php.net/bug.php?id=61033edit=1
ID: 61033
Comment by: kusmierz at o2 dot pl
Reported by:marc at easen dot co dot uk
Summary:__FUNCTION__ doesn't report correctly in alias trait
methods
Status: Not a bug
Type: Bug
Package:Reflection related
Operating System: Gentoo
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
The real example of Not a bug, it's feature!. How can i refere to original
method name then?
Previous Comments:
[2012-02-09 20:44:32] g...@php.net
Forgot to set the status.
[2012-02-09 20:43:18] g...@php.net
While it made sense to change __CLASS__ to report the using class (since a
trait is
not a class), I do not think that it makes much sense to change __FUNCTION__ to
do
such magic.
__FUNCTION__ referes here to the compile time name of the lexical entity the
magic
constant is embedded in. Thus, it is the name you'll find in the code. (since
there
is no lexical entity class, we can fall back to the using class without having
to
explain to much). (And __TRAIT__ is also not changed on usage when composing
traits, it is a lexical reference).
That's what comes to my mind when thinking about this question.
I would suggest that you write a mail to the internals mailing list to start a
discussion. This might still be a controversial thing.
I will classify it as intended behavior for the moment
Thanks (and please start a discussion on the mailing list if you disagree)
Stefan
[2012-02-09 20:23:48] marc at easen dot co dot uk
Description:
The __FUNCTION__ magic constant does not report correctly in aliased methods
within traits.
When a trait function is called by it's initial name __FUNCTION__ is correct.
When it is called by it aliased name __FUNCTION__ still reports as the initial
name, but debug_backtrace() reports the aliased method name.
Test script:
---
?php
trait MyTrait {
public function foo()
{
$backtrace = debug_backtrace();
echo '__FUNCTION__ = ' . __FUNCTION__ . PHP_EOL;
echo '$backtrace[0][\'function\']) = ' .
$backtrace[0]['function'] . PHP_EOL;
}
}
class MyClass {
use MyTrait { foo as public bar; }
}
$instance = new MyClass();
echo 'foo()' . PHP_EOL;
$instance-foo();
echo PHP_EOL;
echo 'bar()' . PHP_EOL;
$instance-bar();
Expected result:
foo()
__FUNCTION__ = foo
$backtrace[0]['function']) = foo
bar()
__FUNCTION__ = bar
$backtrace[0]['function']) = bar
Actual result:
--
foo()
__FUNCTION__ = foo
$backtrace[0]['function']) = foo
bar()
__FUNCTION__ = foo
$backtrace[0]['function']) = bar
--
Edit this bug report at https://bugs.php.net/bug.php?id=61033edit=1
Bug #63413 [Com]: Intermittent warning and fatal error on require() statement
Edit report at https://bugs.php.net/bug.php?id=63413edit=1 ID: 63413 Comment by: giunta dot gaetano at gmail dot com Reported by:ben at indietorrent dot org Summary:Intermittent warning and fatal error on require() statement Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Btw, did some testing on my rig: win7 64bit, apache 2.4.3/vc10 from Apache Lounge, php 5.3.20/vc9. Using the test scripts provided above, and ab hitting them 100 times in a row with concurrency ranging from 1 to 64. When no NTFS junctions in use = no sign of errors whatsoever When an NTFS junction in use = one or two php errors do happen, across the whole test (127k requests). NB: just accessing the main file over the junction is ok. The problems happen then the require call is for a file over in the junction-ed directory Previous Comments: [2013-02-13 17:34:19] giunta dot gaetano at gmail dot com A behaviour which has been puzzling me and that might (or not) be related: we also have some failing code which assumes that filemtime should not be zero (for an existing file). This is generally happening on Linux servers at customers (php in mode_prefork), at times of high load, for nfs-mounted files [2012-11-16 16:29:11] ben at indietorrent dot org Additional testing indicates that this problem is likely related to a specific piece of software that has been installed on the affected machines, and not PHP or the manner in which it is integrated with Apache. I tested the steps-to-reproduce with the exact same project/code-base on a LAMP stack (Ubuntu 12.04 + Apache 2.2.22 + MySQL 5.5.24 + PHP 5.3.10) and cannot reproduce the issue, no matter how hard I hammer the server with requests. As mentioned previously, I am unable to reproduce this issue with a comparable stack on Mac OS 10.8, either. These facts pointed to a Windows-specific cause, perhaps related to Apache's winnt MPM, so I setup a VM with a pristine Windows 7 x86 installation. I installed the same stack components as are installed on the computers on which this issue occurs. Yet, after several hours of hammering the server with constant page-requests, not a single error has been registered in PHP's error log. If at any point I'm able to determine which software causes this issue, I will post my findings here. [2012-11-05 15:45:02] ben at indietorrent dot org Another update. I began to suspect that this is a thread-safety issue, so I downloaded the latest non-thread-safe version of PHP and configured Apache to serve PHP files via Fast-CGI (mod_fcgid). To my surprise, this problem still occurs, and it seems to be worse with Fast-CGI than with Mod-PHP. Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I hammered on Apache, these spurious require() failures did not occur. [2012-11-01 21:07:42] ben at indietorrent dot org It occurred to me to examine Apache's internal error log for entries that correspond to those in PHP's error log when this occurs. I noticed what may be an important clue. Sample entries in PHP's error log: --- [01-Nov-2012 13:29:41 America/New_York] PHP Warning: require(../include/global.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:41 America/New_York] PHP Fatal error: require(): Failed opening required '../include/global.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:43 America/New_York] PHP Warning: require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\include\global.inc.php on line 18 [01-Nov-2012 13:29:43 America/New_York] PHP Fatal error: require(): Failed opening required 'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\include\global.inc.php on line 18 --- Roughly-corresponding entries in Apache's error log:
[PHP-BUG] Bug #64209 [NEW]: mysqli.insert-id return autoincrement not insert id
From: grek at pogodzinach dot net Operating system: ubuntu PHP version: 5.4.11 Package: PHAR related Bug Type: Bug Bug description:mysqli.insert-id return autoincrement not insert id Description: Hy mysqli.insert-id = this is error / bug or please rename funcion mysqli.insert-id to mysqli.autoincrement-value or add to mysqli.insert-id return primary row value - this func return 0 when primary value dont have auto increment Test script: --- any , always ! Expected result: return real insert id = primary rov value -- Edit bug report at https://bugs.php.net/bug.php?id=64209edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64209r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64209r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64209r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64209r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64209r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64209r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64209r=needscript Try newer version: https://bugs.php.net/fix.php?id=64209r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64209r=support Expected behavior: https://bugs.php.net/fix.php?id=64209r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64209r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64209r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64209r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64209r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64209r=dst IIS Stability: https://bugs.php.net/fix.php?id=64209r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64209r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64209r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64209r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64209r=mysqlcfg
[PHP-BUG] Bug #64210 [NEW]: php -l not killed ky SIGTERM
From: ep at numlog dot fr Operating system: linux mint PHP version: 5.3.21 Package: *General Issues Bug Type: Bug Bug description:php -l not killed ky SIGTERM Description: $ php -l $ ps -edf | grep php eric 13374 8672 0 11:38 pts/100:00:00 php -l $ kill 13374 $ ps -edf | grep php eric 13374 8672 0 11:38 pts/100:00:00 php -l $ kill -9 13374 $ ps -edf | grep php Test script: --- When php -l is put as background process without any file to lint, php does not catch SIGTERM and must be kill rougly with kill -9 . -- Edit bug report at https://bugs.php.net/bug.php?id=64210edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64210r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64210r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64210r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64210r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64210r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64210r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64210r=needscript Try newer version: https://bugs.php.net/fix.php?id=64210r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64210r=support Expected behavior: https://bugs.php.net/fix.php?id=64210r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64210r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64210r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64210r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64210r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64210r=dst IIS Stability: https://bugs.php.net/fix.php?id=64210r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64210r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64210r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64210r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64210r=mysqlcfg
[PHP-BUG] Bug #64211 [NEW]: sha256 hashes #, , and + incorrectly.
From: pwormer at science dot ru dot nl Operating system: windows/linux PHP version: 5.4.11 Package: hash related Bug Type: Bug Bug description:sha256 hashes #, , and + incorrectly. Description: The JavaScript functions at: http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha256.js and http://www.movable-type.co.uk/scripts/sha256.html give the same hash for any password of any length consisting of ASCII 32 through 128. Almost always the hash is the same as obtained from PHP: hash(sha256, $pswd). Exceptions (bugs?) are passwords containing one or more of the three characters: # (number sign), (ampersand), or + (plus sign). Tested with XAMPP (PHP 5.4.7), FireFox and Chrome and Linux server. Test script: --- See http://www.theochem.ru.nl/~pwormer/sha256bug.php This URL calls SHA256.php which contains the following four lines ?php $pswd = $_GET[pswd]; echo hash(sha256, $pswd); ? Expected result: I expect JavaScript and PHP to give same Sha-256 hashes Actual result: -- Hash of # (single character): JS: 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b PHP: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -- Edit bug report at https://bugs.php.net/bug.php?id=64211edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64211r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64211r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64211r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64211r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64211r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64211r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64211r=needscript Try newer version: https://bugs.php.net/fix.php?id=64211r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64211r=support Expected behavior: https://bugs.php.net/fix.php?id=64211r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64211r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64211r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64211r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64211r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64211r=dst IIS Stability: https://bugs.php.net/fix.php?id=64211r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64211r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64211r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64211r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64211r=mysqlcfg
Req #52657 [Com]: create a spl_object_id function
Edit report at https://bugs.php.net/bug.php?id=52657edit=1
ID: 52657
Comment by: maciej dot sz at gmail dot com
Reported by:marco dot weber at uni-trier dot de
Summary:create a spl_object_id function
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: ANY
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
An implementation of this is avaliable, and can be compiled as an extension:
http://stackoverflow.com/a/3089587/1697320
Previous Comments:
[2012-11-15 14:55:08] maciej dot sz at gmail dot com
@rasmus at mindplay dot dk: the thing is PHP already creates internal unique
index for each instantiated object. The requested spl_object_id() function
would only have to return it. You may have seen the value of this variable
while debugging your scripts. Have you not noticed the overhead? ;) Just
kidding.
Anyway, your idea for workaround seemed reasonable to me, and now thanks to the
traits in 5.4 I'm able to apply this unique object id to every class that I
need. Just use the below trait. It is also immune to the __get/__set issue. The
downside of this is that the id is a string containing class name. But if I'd
need an id that is unique only within a specific class scope I can use integer
value without the class name:
?php
/**
* Provides unique object's identifier.
*/
trait TObjectUniqueId
{
/**
* Object's unique id.
*
* @var int
*/
protected $__oid__ = null;
/**
* @return string
*/
public function getObjectUniqueId()
{
static $__object_index = 1;
if ( null === $this-__oid__ ) {
$this-__oid__ = __CLASS__ . '\\' . $__object_index++;
}
return $this-__oid__;
}
}
[2011-06-13 14:28:07] rasmus at mindplay dot dk
I don't think attaching a serial number to every object from the get-go is a
good
approach, since this will add overhead (memory and CPU) for every object
constructed. Objects are relatively lightweight in PHP, and sacrificing that
for a
feature that is probably less commonly used, to me, is unacceptable.
What I would propose, is to assign a serial number the first time you access an
object - something along the lines of this:
public function object_serial($object)
{
static $next_sn = 1;
if (!isset($object-__sn__))
$object-__sn__ = $next_sn++;
return $object-__sn__;
}
You don't need to keep a serial-number in-memory until it's actually needed,
and
at that point, we'll just check and see if it already has an assigned serial-
number.
This is much simpler and easier on system-resources - the serial number is much
lighter than the 32-character hash, and will work just as well. And since
you're
most likely going to use this value as index in an array, hash indexes will
take
up less memory, and lookups will probably be cheaper too.
Unfortunately the PHP version of this collides with the magic __set() method,
which is why the function shown above won't always work.
If there were a way to go around the __get() and __set() methods, and directly
access the properties of an object without colliding with these magic methods,
that would probably be an even better solution. I would consider such a feature
as
belonging to the reflection domain - something like
ReflectionObject::getValue($object, $name) and
ReflectionObject::setValue($object,
$name, $value) would do the trick.
(this would probably have other uses too, so perhaps that's an even better
solution to this problem, seeing as how implementing your own object_serial()
method is literally only a few lines of code...)
[2011-06-13 10:44:11] marco dot weber at uni-trier dot de
i know, that there is nothing wrong with that method, as it does exactly, what
the documentation says. Nevertheless, it would be great to have another
function like spl_object_id(), that generates unique ids...
Quotation from [2010-08-20 15:34 UTC] marco dot weber at uni-trier dot de :
Since there is nothing wrong, with the spl_object_hash() method, i suggest to
introduce a new spl_object_id() function. This could simply return an
(internal) uint32, that is attached to every object on its creation. This
counter gets incremented on every object that gets created. :)
[2011-06-13 04:18:41] rasmus at mindplay dot dk
I agree, this is a vital feature.
Also, the description of spl_object_hash() in the documentation is highly
misleading:
This function returns a unique identifier for the object. This id can be used
as a hash key for storing objects or for identifying an
Bug #64209 [Opn-Nab]: mysqli.insert-id return autoincrement not insert id
Edit report at https://bugs.php.net/bug.php?id=64209edit=1 ID: 64209 Updated by: johan...@php.net Reported by:grek at pogodzinach dot net Summary:mysqli.insert-id return autoincrement not insert id -Status: Open +Status: Not a bug Type: Bug -Package:PHAR related +Package:MySQLi related Operating System: ubuntu PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Insert ID is a term used by MySQL. If you want to change this, ask Oracle to fix this in MySQL. There is no reason for PHP to use different terminology. Previous Comments: [2013-02-14 10:46:40] grek at pogodzinach dot net Description: Hy mysqli.insert-id = this is error / bug or please rename funcion mysqli.insert-id to mysqli.autoincrement-value or add to mysqli.insert-id return primary row value - this func return 0 when primary value dont have auto increment Test script: --- any , always ! Expected result: return real insert id = primary rov value -- Edit this bug report at https://bugs.php.net/bug.php?id=64209edit=1
[PHP-BUG] Req #64212 [NEW]: Ability to reference an active output buffer stack.
From: aleksandr dot makov at gmail dot com Operating system: Any PHP version: Irrelevant Package: Output Control Bug Type: Feature/Change Request Bug description:Ability to reference an active output buffer stack. Description: Since we have ob_get_level() we kind of miss ability to reference that stack from nested active stacks. In recursive content generators this will avoid the need to loop through the final output to determine the bounds of nested stacks and do operations with that(those) segment(s), such as replacement and so on. Test script: --- ob_start(); echo 111; // -- this is the stack of interest ob_start(); echo 22; ob_start(); echo 3; $cur_stack_len = ob_get_length(); // length of current stack (level 3) is 1 $top_stack_len = get_length_of_ob_stack_by_level(1); // expected length here should be 3 (strlen(111) == 3) ob_end_clean(); ob_end_clean(); echo some more chars to change length of stack 1; ob_end_clean(); echo $top_stack_len; // I'm expecting to see 3 here. Expected result: 3 Actual result: -- not implemented -- Edit bug report at https://bugs.php.net/bug.php?id=64212edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64212r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64212r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64212r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64212r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64212r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64212r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64212r=needscript Try newer version: https://bugs.php.net/fix.php?id=64212r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64212r=support Expected behavior: https://bugs.php.net/fix.php?id=64212r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64212r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64212r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64212r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64212r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64212r=dst IIS Stability: https://bugs.php.net/fix.php?id=64212r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64212r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64212r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64212r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64212r=mysqlcfg
Bug #64210 [Opn]: php -l not killed ky SIGTERM
Edit report at https://bugs.php.net/bug.php?id=64210edit=1 ID: 64210 User updated by:ep at numlog dot fr Reported by:ep at numlog dot fr Summary:php -l not killed ky SIGTERM Status: Open Type: Bug Package:*General Issues Operating System: linux mint PHP Version:5.3.21 Block user comment: N Private report: N New Comment: $ php -l [3] 17456 $ kill % -- works ! And $ php -l [4] 14304 $ fg php -l Complété- Works when 14304 killed from another shell Previous Comments: [2013-02-14 10:51:28] ep at numlog dot fr Description: $ php -l $ ps -edf | grep php eric 13374 8672 0 11:38 pts/100:00:00 php -l $ kill 13374 $ ps -edf | grep php eric 13374 8672 0 11:38 pts/100:00:00 php -l $ kill -9 13374 $ ps -edf | grep php Test script: --- When php -l is put as background process without any file to lint, php does not catch SIGTERM and must be kill rougly with kill -9 . -- Edit this bug report at https://bugs.php.net/bug.php?id=64210edit=1
Bug #64077 [Fbk-Csd]: Use of self keyword causing error
Edit report at https://bugs.php.net/bug.php?id=64077edit=1
ID: 64077
User updated by:iceman2g2 at gmail dot com
Reported by:iceman2g2 at gmail dot com
Summary:Use of self keyword causing error
-Status: Feedback
+Status: Closed
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This issue has been tracked down. It seems the issue revolved around calling a
method that
wasn't declared as static in a static manner.
So a method defined as:
public function getById($flight)
Was changed to:
public static function getById($flight)
Previous Comments:
[2013-01-26 11:57:25] cataphr...@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 ?php and ends 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.
[2013-01-25 20:53:11] iceman2g2 at gmail dot com
Description:
PHP Version: 5.3.17
Server API: CGI/FastCGI
I'm using the self keyword to call a method that's defined in an abstract
class.
The call to the method itself is being made within the abstract class. The
method is both private and static.
Here's a definition of the method:
private static function _executeCallback($sequence, $event, array $param =
array(), Dhonki_Model
$object = NULL)
This is the snippet of code that calls the method:
if (isset(self::$_event_callback[$model]['find']['after']) ||
isset(self::$_event_callback[__CLASS__]['find']['after'])) {
self::_executeCallback('after', 'find', $param,
$object);
}
The problem comes with the use of:
self::_executeCallback('after', 'find', $param, $object);
To fix the error I use the code:
Dhonki_Model::_executeCallback('after', 'find', $param, $object);
I don't know if this is an error related to something I'm doing or if it's a
bug. Again this same code works on several other servers, and in fact works
several other places in the class.
Clayton
Expected result:
I expected self::_executeCallback and Dhonki_Model::_executeCallback to be
functionally equivalent. In fact they seem to be functionally equivalent on
several other servers using this code. The also seem to be equivalent elsewhere
in
the same abstract class that use the self::_executeCallback.
Actual result:
--
Unable to autoload `t6exla` class or interface.
I'm not sure where the t6exla is coming from as the name of my class is
Dhonki_Model.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64077edit=1
Bug #63688 [Opn-Wfx]: setlocale() fails on TS build
Edit report at https://bugs.php.net/bug.php?id=63688edit=1 ID: 63688 Updated by: a...@php.net Reported by:a...@php.net Summary:setlocale() fails on TS build -Status: Open +Status: Wont fix Type: Bug Package:*General Issues Operating System: Windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: looks like this isn't fixable in PHP Previous Comments: [2013-02-09 19:46:47] charnad at gmail dot com Bug can be reproduced on all thread safe versions above 5.3.5 (5.3.6 - 5.4.9 for the moment) in CLI mode. Bug does not reproduce on all non-thread safe versions. [2012-12-04 17:41:56] a...@php.net Description: CLI TS build fails to set the locale The relevant place in the code seems to be this: http://lxr.php.net/xref/PHP_5_3/main/SAPI.c#82 Extending this code right in place like _configthreadlocale(_ENABLE_PER_THREAD_LOCALE) setlocale(LC_ALL, german); lcnv = localeconv(); lcl = _get_current_locale(); and checking then *lcnv-decimal_point == ',' results in false. As well other values of the lconv scruct don't correspond to the set locale (german in this case). _configthreadlocale()is not invoked in the NTS builds and setlocale works correct there. Test script: --- Those two tests tests\lang\034.phpt tests\lang\bug30638.phpt a simpler test case ?php echo setlocale(LC_NUMERIC, 'german') . \n; echo (float)'3.14\n'; Expected result: German_Germany.1252 3,14 Actual result: -- German_Germany.1252 3.14 -- Edit this bug report at https://bugs.php.net/bug.php?id=63688edit=1
Bug #44999 [Com]: 0 equals any string
Edit report at https://bugs.php.net/bug.php?id=44999edit=1 ID: 44999 Comment by: radamanf at gmail dot com Reported by:ethan dot nelson at ltd dot org Summary:0 equals any string Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: windows 2003 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: I can see that it's no any logical explanation to keep this BUG unfixed! Status: Not a bug - why??? It's not funny, so many years past. I do love to use PHP and like that no needed to define variable types, but this is generic FAIL. Come one guys, someone need to fix this, please. My PHP version PHP 5.3.10-1ubuntu3.5 with Suhosin-Patch (cli) (built: Jan 18 2013 23:45:59) Previous Comments: [2012-08-24 08:16:07] bugs dot php dot net at simoneast dot net This is quite ridiculous. Can this 'feature' of PHP *please* be reconsidered? [2008-05-14 22:25:51] ethan dot nelson at ltd dot org I don't recall PHP ever behaving that way. So how do you alter a switch statement to use the identical operator instead of equivalency? It seems somewhat odd that any text character would be equvalent to integer 0. As I remember the chart it was something like: 0 == '0' true 0 == '' true 0 == null true 0 == false true 0 == 'text' false Basically if we are going to treat any string as equivalent to 0, the switch statement becomes useless when iterating through arrays unless you first strip key names of integer 0. [2008-05-14 22:20:01] cel...@php.net see Bug #44990 for explanation [2008-05-14 21:51:49] ethan dot nelson at ltd dot org Description: Right now, 0 compared to any string will prove true. Reproduce code: --- ?php if (0 == 'anystring') echo True; else echo False; ? Expected result: False Actual result: -- True -- Edit this bug report at https://bugs.php.net/bug.php?id=44999edit=1
Bug #44990 [Com]: array('word')==array(0) -- true
Edit report at https://bugs.php.net/bug.php?id=44990edit=1
ID: 44990
Comment by: radamanf at gmail dot com
Reported by:design at apostolstudio dot com
Summary:array('word')==array(0) -- true
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows XP
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
Comparison === needed ONLY if, during type conversion, we got same values, so
String compare to Integer should be compared using Integer converted to string
and check if they are equal.
So if String is '' and Int is 0
or '1' == 1
'2' == 2
.. etc. only in this cases === is necessary to tell VARIABLE TYPE difference.
It's so obvious, why I'm explaining all this to you ?! You should know this
better than me! Please fix this BUG
Previous Comments:
[2008-05-14 02:58:01] design at apostolstudio dot com
Thanks for explanations.
[2008-05-14 02:39:53] cel...@php.net
use ===
'word' is converted to an integer for the comparison, and thus 0 == 0.
try this code:
if(array('word')===array(0)) echo ERROR;
[2008-05-14 02:27:10] design at apostolstudio dot com
Description:
array('word')==array(0) -- return true
Reproduce code:
---
if(array('word')==array(0)) echo ERROR;
Actual result:
--
ERROR
--
Edit this bug report at https://bugs.php.net/bug.php?id=44990edit=1
Bug #39579 [Com]: Comparing zero string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579edit=1 ID: 39579 Comment by: radamanf at gmail dot com Reported by:iain at workingsoftware dot com dot au Summary:Comparing zero string values in boolean comparison has unexpected behaviour Status: Not a bug Type: Bug Package:Variables related Operating System: FreeBSD 6.1 PHP Version:5.2.0 Block user comment: N Private report: N New Comment: This is a epic FAIL in pure logic of comparing formats not having explicitly defining them, whole beauty of PHP disappear! This is BROKEN LOGIC. Connected BUGS Bug #44990 Bug #39579 Different people are coming across this BUG and thinking the same as me, so please CHANGE your documentation, it's WRONG! Who is this GENIES to make possible converting String to Integer NOT INT TO STRING! Guys, I'm very disappointed! :) Previous Comments: [2013-02-14 17:14:35] radamanf at gmail dot com This is a epic FAIL in pure logic of comparing formats not having explicitly defining them, whole beauty of PHP disappear! This is BROKEN LOGIC. Connected BUGS Bug #44990 Bug #39579 Different people are coming across this BUG and thinking the same as me, so please CHANGE your documentation, it's WRONG! Who is this GENIES to make possible converting String to Integer NOT INT TO STRING! Guys, I'm very disappointed! :) [2012-08-01 10:31:16] v dot picture at free dot fr Hi, I'm wondering why this comparison should be evaluated in a numeric context and not a string context, after all there is no loss with string casting whereas there is a huge risk of doing mistakes with numeric casting: (string) 0 = 0 (string) 42.5 = 42.5 (int) test = 0 But ok, let's say it's a normal behavior. If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number Then why would PHP decide to do that in a string context ? I mean, when I compare two strings I don't expect PHP to convert everything to numbers ! 10 == 1e1 = true Sorry folks, this really seems like a string context to me. [2006-11-22 11:36:19] m...@php.net It's not a problem -- it's a feature, and it's documented at the address I've just quoted, which describes evaluation of a string in any numeric context. [2006-11-22 11:14:47] iain at workingsoftware dot com dot au it's not the behaviour of how a string is cast to an integer that i'm talking about, but if i have a comparison: if($value == Class::CONSTANT) and the class constant is a string, it's not immediately apparent that if $value == 0 then this will evaluate to true. maybe warning is too strong, but a notice might be good in the event that a non-strict == operation returns true because one of the operands is 0 and the other operand is a value that evaluates to 0 when cast as an int. anyway, i guess if php has been around for this long without anyone mentioning it yet ... i mean, this is the first time i've come across the problem. if a notice had been emitted it would have been a time saver. [2006-11-22 11:06:57] m...@php.net And, besides, this behaviour is documented at http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion 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=39579 -- Edit this bug report at https://bugs.php.net/bug.php?id=39579edit=1
Bug #44990 [Nab]: array('word')==array(0) -- true
Edit report at https://bugs.php.net/bug.php?id=44990edit=1
ID: 44990
Updated by: ni...@php.net
Reported by:design at apostolstudio dot com
Summary:array('word')==array(0) -- true
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows XP
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
@radamanf: He is comparing with == so all array elements are also compared with
==. And as in PHP 'word'==0 they are considered equal. Are you suggesting that
when you compare arrays with == the elements should be compared with ===? That
makes no sense to me.
Previous Comments:
[2013-02-14 17:14:35] radamanf at gmail dot com
Related To: Bug #39579
[2013-02-14 16:59:12] radamanf at gmail dot com
Comparison === needed ONLY if, during type conversion, we got same values, so
String compare to Integer should be compared using Integer converted to string
and check if they are equal.
So if String is '' and Int is 0
or '1' == 1
'2' == 2
.. etc. only in this cases === is necessary to tell VARIABLE TYPE difference.
It's so obvious, why I'm explaining all this to you ?! You should know this
better than me! Please fix this BUG
[2008-05-14 02:58:01] design at apostolstudio dot com
Thanks for explanations.
[2008-05-14 02:39:53] cel...@php.net
use ===
'word' is converted to an integer for the comparison, and thus 0 == 0.
try this code:
if(array('word')===array(0)) echo ERROR;
[2008-05-14 02:27:10] design at apostolstudio dot com
Description:
array('word')==array(0) -- return true
Reproduce code:
---
if(array('word')==array(0)) echo ERROR;
Actual result:
--
ERROR
--
Edit this bug report at https://bugs.php.net/bug.php?id=44990edit=1
Bug #39579 [Nab]: Comparing zero string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579edit=1
ID: 39579
Updated by: ni...@php.net
Reported by:iain at workingsoftware dot com dot au
Summary:Comparing zero string values in boolean comparison
has unexpected behaviour
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: FreeBSD 6.1
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
@radamanf: Stop shouting. Shouting does not help.
I agree that this behavior ('foo' == 0) is counter-productive. I think most
people would agree on that. But even if everyone agrees that it's the wrong
behavior, changing it isn't so easy. Changing this behavior will probably break
existing software.
If you really want to change this, then there is only one way: Make the change
and then test a shitload of code against it. See how many tests will fail in
major PHP projects and how easy things are to fix.
If you can provide sufficient data that this change (which goes rather deep
into the core semantics of the language) won't affect existing projects
heavily, then I see no problem with doing it.
Previous Comments:
[2013-02-14 17:14:35] radamanf at gmail dot com
Related To: Bug #39579
[2013-02-14 17:14:35] radamanf at gmail dot com
This is a epic FAIL in pure logic of comparing formats not having explicitly
defining them, whole beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so
please CHANGE your documentation, it's WRONG! Who is this GENIES to make
possible converting String to Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
[2012-08-01 10:31:16] v dot picture at free dot fr
Hi, I'm wondering why this comparison should be evaluated in a numeric context
and not a string context, after all
there is no loss with string casting whereas there is a huge risk of doing
mistakes with numeric casting:
(string) 0 = 0
(string) 42.5 = 42.5
(int) test = 0
But ok, let's say it's a normal behavior.
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to
a number
Then why would PHP decide to do that in a string context ? I mean, when I
compare two strings I don't expect PHP to
convert everything to numbers !
10 == 1e1 = true
Sorry folks, this really seems like a string context to me.
[2006-11-22 11:36:19] m...@php.net
It's not a problem -- it's a feature, and it's documented at the address I've
just quoted, which describes evaluation of a string in any numeric context.
[2006-11-22 11:14:47] iain at workingsoftware dot com dot au
it's not the behaviour of how a string is cast to an integer that i'm talking
about, but if i have a comparison:
if($value == Class::CONSTANT)
and the class constant is a string, it's not immediately apparent that if
$value == 0 then this will evaluate to true. maybe warning is too strong, but a
notice might be good in the event that a non-strict == operation returns true
because one of the operands is 0 and the other operand is a value that
evaluates to 0 when cast as an int.
anyway, i guess if php has been around for this long without anyone mentioning
it yet ... i mean, this is the first time i've come across the problem. if a
notice had been emitted it would have been a time saver.
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=39579
--
Edit this bug report at https://bugs.php.net/bug.php?id=39579edit=1
Bug #39579 [Com]: Comparing zero string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579edit=1
ID: 39579
Comment by: radamanf at gmail dot com
Reported by:iain at workingsoftware dot com dot au
Summary:Comparing zero string values in boolean comparison
has unexpected behaviour
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: FreeBSD 6.1
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
I've seen a topic in the web:
http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/ related to
this bug, and I can see that sometimes string need to be compared with integer
as integer BUT this is a huge pool of potential bugs across all the worldwide!
:) Can you imagine how many people usign PHP without realizing this BUG ! :)_)
I'm sure this is a loved BUG by most hackers out there !
Previous Comments:
[2013-02-14 17:24:51] ni...@php.net
@radamanf: Stop shouting. Shouting does not help.
I agree that this behavior ('foo' == 0) is counter-productive. I think most
people would agree on that. But even if everyone agrees that it's the wrong
behavior, changing it isn't so easy. Changing this behavior will probably break
existing software.
If you really want to change this, then there is only one way: Make the change
and then test a shitload of code against it. See how many tests will fail in
major PHP projects and how easy things are to fix.
If you can provide sufficient data that this change (which goes rather deep
into the core semantics of the language) won't affect existing projects
heavily, then I see no problem with doing it.
[2013-02-14 17:14:35] radamanf at gmail dot com
Related To: Bug #39579
[2013-02-14 17:14:35] radamanf at gmail dot com
This is a epic FAIL in pure logic of comparing formats not having explicitly
defining them, whole beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so
please CHANGE your documentation, it's WRONG! Who is this GENIES to make
possible converting String to Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
[2012-08-01 10:31:16] v dot picture at free dot fr
Hi, I'm wondering why this comparison should be evaluated in a numeric context
and not a string context, after all
there is no loss with string casting whereas there is a huge risk of doing
mistakes with numeric casting:
(string) 0 = 0
(string) 42.5 = 42.5
(int) test = 0
But ok, let's say it's a normal behavior.
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to
a number
Then why would PHP decide to do that in a string context ? I mean, when I
compare two strings I don't expect PHP to
convert everything to numbers !
10 == 1e1 = true
Sorry folks, this really seems like a string context to me.
[2006-11-22 11:36:19] m...@php.net
It's not a problem -- it's a feature, and it's documented at the address I've
just quoted, which describes evaluation of a string in any numeric context.
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=39579
--
Edit this bug report at https://bugs.php.net/bug.php?id=39579edit=1
Bug #63976 [PATCH]: Parent class incorrectly using child constant in class property
Edit report at https://bugs.php.net/bug.php?id=63976edit=1 ID: 63976 Patch added by: m...@php.net Reported by:don at smugmug dot com Summary:Parent class incorrectly using child constant in class property Status: Open Type: Bug Package:Class/Object related Operating System: Ubuntu 12.04 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: update_class_constants Revision: 1360863036 URL: https://bugs.php.net/patch-display.php?bug=63976patch=update_class_constantsrevision=1360863036 Previous Comments: [2013-01-12 03:53:33] don at smugmug dot com 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. [2013-01-12 03:51:21] don at smugmug dot com Description: Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: Consistent results for Baz-table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz-table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz-table == 'foo' in the examples). Actual result: -- brokenA.php: Bar Object ( [table] = bar ) Baz Object ( [table] = foo ) brokenB.php: Bar Object ( [table] = bar ) Baz Object ( [table] = baz ) brokenC.php: Baz Object ( [table] = baz ) Bar Object ( [table] = bar ) Baz Object ( [table] = baz ) -- Edit this bug report at https://bugs.php.net/bug.php?id=63976edit=1
Bug #64211 [Opn-Nab]: sha256 hashes #, , and + incorrectly.
Edit report at https://bugs.php.net/bug.php?id=64211edit=1 ID: 64211 Updated by: s...@php.net Reported by:pwormer at science dot ru dot nl Summary:sha256 hashes #, , and + incorrectly. -Status: Open +Status: Not a bug Type: Bug Package:hash related Operating System: windows/linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Can't reproduce on 32 or 64 bit Linux: $ php53 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b $ php54 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b Is it coincidence that (an empty string) gives the hash you are expecting for #. $ php53 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $ php54 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Previous Comments: [2013-02-14 11:05:56] pwormer at science dot ru dot nl Description: The JavaScript functions at: http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha256.js and http://www.movable-type.co.uk/scripts/sha256.html give the same hash for any password of any length consisting of ASCII 32 through 128. Almost always the hash is the same as obtained from PHP: hash(sha256, $pswd). Exceptions (bugs?) are passwords containing one or more of the three characters: # (number sign), (ampersand), or + (plus sign). Tested with XAMPP (PHP 5.4.7), FireFox and Chrome and Linux server. Test script: --- See http://www.theochem.ru.nl/~pwormer/sha256bug.php This URL calls SHA256.php which contains the following four lines ?php $pswd = $_GET[pswd]; echo hash(sha256, $pswd); ? Expected result: I expect JavaScript and PHP to give same Sha-256 hashes Actual result: -- Hash of # (single character): JS: 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b PHP: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -- Edit this bug report at https://bugs.php.net/bug.php?id=64211edit=1
Bug #64211 [Nab]: sha256 hashes #, , and + incorrectly.
Edit report at https://bugs.php.net/bug.php?id=64211edit=1 ID: 64211 Updated by: s...@php.net Reported by:pwormer at science dot ru dot nl Summary:sha256 hashes #, , and + incorrectly. Status: Not a bug Type: Bug Package:hash related Operating System: windows/linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: s/expecting/getting Previous Comments: [2013-02-14 21:37:50] s...@php.net Can't reproduce on 32 or 64 bit Linux: $ php53 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b $ php54 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b Is it coincidence that (an empty string) gives the hash you are expecting for #. $ php53 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $ php54 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 [2013-02-14 11:05:56] pwormer at science dot ru dot nl Description: The JavaScript functions at: http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha256.js and http://www.movable-type.co.uk/scripts/sha256.html give the same hash for any password of any length consisting of ASCII 32 through 128. Almost always the hash is the same as obtained from PHP: hash(sha256, $pswd). Exceptions (bugs?) are passwords containing one or more of the three characters: # (number sign), (ampersand), or + (plus sign). Tested with XAMPP (PHP 5.4.7), FireFox and Chrome and Linux server. Test script: --- See http://www.theochem.ru.nl/~pwormer/sha256bug.php This URL calls SHA256.php which contains the following four lines ?php $pswd = $_GET[pswd]; echo hash(sha256, $pswd); ? Expected result: I expect JavaScript and PHP to give same Sha-256 hashes Actual result: -- Hash of # (single character): JS: 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b PHP: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -- Edit this bug report at https://bugs.php.net/bug.php?id=64211edit=1
Bug #39579 [Nab]: Comparing zero string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579edit=1
ID: 39579
User updated by:iain at workingsoftware dot com dot au
Reported by:iain at workingsoftware dot com dot au
Summary:Comparing zero string values in boolean comparison
has unexpected behaviour
Status: Not a bug
Type: Bug
Package:Variables related
Operating System: FreeBSD 6.1
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
Hi, I agree this shouldn't be changed. It's pretty fundamental to how PHP works
and since reporting this bug 6
years ago I've learned a lot more about PHP :)
I still think my suggestion of emitting a Notice whenever a string is converted
to 0 as a result of being
evaluated in a numeric context isn't too outlandish though.
*Changing* the way that strings are evaluated would break a buttload of code
and
isn't really productive.
Emitting a Notice would help people unfamiliar with the implicit typecasting
behaviour save some time and
avoid bugs when developing. For those that like to write clean code with no
Notices there is a very simple
way of suppressing it (ie. use === or (int)).
Also, emitting a notice wouldn't actually break any code, although it might
cause a number of scripts out in
the wild to become more verbose in their logging - is that not an acceptable
risk?
The notice could even say something like:
Notice: String evaluated to 0 (zero) when used in numeric context on line
WHATEVER. Use === or (int) to
prevent this notice.
This would enable people to quickly understand the behaviour (which is kind of
unintuitive but fair enough
when you look at PHPs type system - just a foible of the language everyone
should learn) and encourage people
to learn the importance of === earlier on.
Previous Comments:
[2013-02-14 17:26:40] radamanf at gmail dot com
I've seen a topic in the web:
http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/ related to
this bug, and I can see that sometimes string need to be compared with integer
as integer BUT this is a huge pool of potential bugs across all the worldwide!
:) Can you imagine how many people usign PHP without realizing this BUG ! :)_)
I'm sure this is a loved BUG by most hackers out there !
[2013-02-14 17:24:51] ni...@php.net
@radamanf: Stop shouting. Shouting does not help.
I agree that this behavior ('foo' == 0) is counter-productive. I think most
people would agree on that. But even if everyone agrees that it's the wrong
behavior, changing it isn't so easy. Changing this behavior will probably break
existing software.
If you really want to change this, then there is only one way: Make the change
and then test a shitload of code against it. See how many tests will fail in
major PHP projects and how easy things are to fix.
If you can provide sufficient data that this change (which goes rather deep
into the core semantics of the language) won't affect existing projects
heavily, then I see no problem with doing it.
[2013-02-14 17:14:35] radamanf at gmail dot com
Related To: Bug #39579
[2013-02-14 17:14:35] radamanf at gmail dot com
This is a epic FAIL in pure logic of comparing formats not having explicitly
defining them, whole beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so
please CHANGE your documentation, it's WRONG! Who is this GENIES to make
possible converting String to Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
[2012-08-01 10:31:16] v dot picture at free dot fr
Hi, I'm wondering why this comparison should be evaluated in a numeric context
and not a string context, after all
there is no loss with string casting whereas there is a huge risk of doing
mistakes with numeric casting:
(string) 0 = 0
(string) 42.5 = 42.5
(int) test = 0
But ok, let's say it's a normal behavior.
If you compare a number with a string or the comparison involves numerical
strings, then each string is converted to
a number
Then why would PHP decide to do that in a string context ? I mean, when I
compare two strings I don't expect PHP to
convert everything to numbers !
10 == 1e1 = true
Sorry folks, this really seems like a string context to me.
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=39579
Bug-Req #39579 [Nab]: Comparing zero string values in boolean comparison has unexpected behaviour
Edit report at https://bugs.php.net/bug.php?id=39579edit=1
ID: 39579
User updated by:iain at workingsoftware dot com dot au
Reported by:iain at workingsoftware dot com dot au
Summary:Comparing zero string values in boolean comparison
has unexpected behaviour
Status: Not a bug
-Type: Bug
+Type: Feature/Change Request
Package:Variables related
Operating System: FreeBSD 6.1
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
Sorry I meant to submit this as Feature/Change Request but submitted the form
without a password and it changed back to bug.
Previous Comments:
[2013-02-14 22:50:15] iain at workingsoftware dot com dot au
Hi, I agree this shouldn't be changed. It's pretty fundamental to how PHP works
and since reporting this bug 6
years ago I've learned a lot more about PHP :)
I still think my suggestion of emitting a Notice whenever a string is converted
to 0 as a result of being
evaluated in a numeric context isn't too outlandish though.
*Changing* the way that strings are evaluated would break a buttload of code
and
isn't really productive.
Emitting a Notice would help people unfamiliar with the implicit typecasting
behaviour save some time and
avoid bugs when developing. For those that like to write clean code with no
Notices there is a very simple
way of suppressing it (ie. use === or (int)).
Also, emitting a notice wouldn't actually break any code, although it might
cause a number of scripts out in
the wild to become more verbose in their logging - is that not an acceptable
risk?
The notice could even say something like:
Notice: String evaluated to 0 (zero) when used in numeric context on line
WHATEVER. Use === or (int) to
prevent this notice.
This would enable people to quickly understand the behaviour (which is kind of
unintuitive but fair enough
when you look at PHPs type system - just a foible of the language everyone
should learn) and encourage people
to learn the importance of === earlier on.
[2013-02-14 17:26:40] radamanf at gmail dot com
I've seen a topic in the web:
http://josephscott.org/archives/2012/03/why-php-strings-equal-zero/ related to
this bug, and I can see that sometimes string need to be compared with integer
as integer BUT this is a huge pool of potential bugs across all the worldwide!
:) Can you imagine how many people usign PHP without realizing this BUG ! :)_)
I'm sure this is a loved BUG by most hackers out there !
[2013-02-14 17:24:51] ni...@php.net
@radamanf: Stop shouting. Shouting does not help.
I agree that this behavior ('foo' == 0) is counter-productive. I think most
people would agree on that. But even if everyone agrees that it's the wrong
behavior, changing it isn't so easy. Changing this behavior will probably break
existing software.
If you really want to change this, then there is only one way: Make the change
and then test a shitload of code against it. See how many tests will fail in
major PHP projects and how easy things are to fix.
If you can provide sufficient data that this change (which goes rather deep
into the core semantics of the language) won't affect existing projects
heavily, then I see no problem with doing it.
[2013-02-14 17:14:35] radamanf at gmail dot com
Related To: Bug #39579
[2013-02-14 17:14:35] radamanf at gmail dot com
This is a epic FAIL in pure logic of comparing formats not having explicitly
defining them, whole beauty of PHP disappear! This is BROKEN LOGIC.
Connected BUGS
Bug #44990
Bug #39579
Different people are coming across this BUG and thinking the same as me, so
please CHANGE your documentation, it's WRONG! Who is this GENIES to make
possible converting String to Integer NOT INT TO STRING!
Guys, I'm very disappointed! :)
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=39579
--
Edit this bug report at https://bugs.php.net/bug.php?id=39579edit=1
[PHP-BUG] Bug #64214 [NEW]: PHAR PHPTs intermittently crash when run on DFS or SMB
From: mattficken Operating system: Windows PHP version: 5.5.0alpha4 Package: PHAR related Bug Type: Bug Bug description:PHAR PHPTs intermittently crash when run on DFS or SMB Description: I am running PHPT tests on an SMB file share (and also sometimes DFS) served by a remote file server. The share is mounted to a local drive (H:) on Windows. This issue occurs on Windows 7, Vista, 2008, 2008r2, 8, 2012, x64 and x86 (I am using the PHP on Windows binary build from windows.php.net without any modification). When I run these 2 PHAR tests, sometimes, they crash: ext/phar/tests/zip/phar_commitwrite.phpt ext/phar/tests/tar/phar_setsignaturealgo2.phpt See attached BTs. If I add additional traffic to the network or file server (ex: download a big file on another computer), the crashes happen more frequently. Even then, I'm only adding max ~10MiB/S to network or file server which isn't really heavy load. The file access times on the share are still pretty normal (fraction of a second max, to read a PHPT file, so the network or file server is never heavily loaded). I believe this is a time issue that is load induced. Actual result: -- ext/phar/tests/zip/phar_commitwrite.phpt php5ts.dll!_php_stream_write(_php_stream * stream, const char * buf, unsigned int count, void * * * tsrm_ls) Line 1233 + 0x10 bytes C php5ts.dll!phar_zip_flush(_phar_archive_data * phar, char * user_stub, long len, int defaultstub, char * * error, void * * * tsrm_ls) Line 1304 + 0x18 bytes C php5ts.dll!phar_flush(_phar_archive_data * phar, char * user_stub, long len, int convert, char * * error, void * * * tsrm_ls) Line 2601 + 0x18 bytes C php5ts.dll!phar_add_file(_phar_archive_data * * pphar, char * filename, int filename_len, char * cont_str, int cont_len, _zval_struct * zresource, void * * * tsrm_ls) Line 3737 + 0x11 bytesC php5ts.dll!zim_Phar_offsetSet(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls) Line 3818 + 0x14 bytes C php5ts.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache, void * * * tsrm_ls) Line 959 + 0x1f bytes C php5ts.dll!zend_call_method(_zval_struct * * object_pp, _zend_class_entry * obj_ce, _zend_function * * fn_proxy, const char * function_name, int function_name_len, _zval_struct * * retval_ptr_ptr, int param_count, _zval_struct * arg1, _zval_struct * arg2, void * * * tsrm_ls) Line 97 + 0x14 bytes C php5ts.dll!zend_std_write_dimension(_zval_struct * object, _zval_struct * offset, _zval_struct * value, void * * * tsrm_ls) Line 678 + 0x1e bytes C php5ts.dll!ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 32607 + 0xbc bytes C ext/phar/tests/tar/phar_setsignaturealgo2.phpt php5ts.dll!user_wrapper_opener(_php_stream_wrapper * wrapper, char * filename, char * mode, int options, char * * opened_path, _php_stream_context * context, void * * * tsrm_ls) Line 346 + 0x2f bytes C php5ts.dll!_php_stream_open_wrapper_ex(char * path, char * mode, int options, char * * opened_path, _php_stream_context * context, void * * * tsrm_ls) Line 2054 + 0x24 bytes C php5ts.dll!php_if_fopen(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls) Line 869 + 0x1a bytes C php5ts.dll!phar_fopen(int ht, _zval_struct * return_value, _zval_struct * * return_value_ptr, _zval_struct * this_ptr, int return_value_used, void * * * tsrm_ls) Line 418 + 0x22 bytes C php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 542 + 0x5e bytes C php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 2305 + 0xb bytes C php5ts.dll!execute_ex(_zend_execute_data * execute_data, void * * * tsrm_ls) Line 356 + 0xa bytes C php5ts.dll!zend_execute(_zend_op_array * op_array, void * * * tsrm_ls) Line 381 + 0x1bc bytes C php5ts.dll!zend_execute_scripts(int type, void * * * tsrm_ls, _zval_struct * * retval, int file_count, ...) Line 1317 C php5ts.dll!php_execute_script(_zend_file_handle * primary_file, void * * * tsrm_ls) Line 2478 + 0x12 bytes C php5apache2_4.dll!php_handler(request_rec * r) Line 667 + 0xe bytesC -- Edit bug report at https://bugs.php.net/bug.php?id=64214edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64214r=trysnapshot54 Try a snapshot (PHP 5.3):
