[PHP-BUG] Bug #51742 [NEW]: A non well formed numeric value encountered
From:
Operating system: All
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:A non well formed numeric value encountered
Description:
PDOException extends RuntimeException which in turn extends Exception. The
Exception class has the following constructor:
public __construct ([ string $message = [, int $code = 0 [, Exception
$previous = NULL ]]] )
The $code parameter is to be of type integer. However, when using pdo_odbc
or
pdo_dblib, the error code returned by the server may be a string, rather
than an
integer. So, for example, calling $e-getCode() may yield a value of
12X34.
This is inconsistent with the method definition as well:
final public int getCode ( void )
PHP's own internal library should not produce outcomes that are in conflict
with
PHP's definitions.
Test script:
---
try
{
$pdo-query( 'BAD QUERY' );
}
catch ( PDOException $e )
{
throw new Exception( $e-getMessage(), $e-getCode() );
}
Expected result:
// Just a thrown exception, nothing important
Actual result:
--
PHP Notice: A non well formed numeric value encountered in [...] on line 7
--
Edit bug report at http://bugs.php.net/bug.php?id=51742edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51742r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51742r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51742r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51742r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51742r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51742r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51742r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51742r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51742r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51742r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51742r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51742r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51742r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51742r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51742r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51742r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51742r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51742r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51742r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51742r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51742r=mysqlcfg
Bug #51542 [Com]: Overriding method type hint with child interface raises strict standards
Edit report at http://bugs.php.net/bug.php?id=51542edit=1
ID: 51542
Comment by: mike at mikegerwitz dot com
Reported by: mike at mikegerwitz dot com
Summary: Overriding method type hint with child interface
raises strict standards
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 5.3.2
New Comment:
Ah - seems you are correct. I must have tested improperly. I was not
aware that
the strict standard warning was raised for classes as well. I'm aware of
the
design flaws in the above example; I thought PHP was just behaving
inconsistently
between classes and interfaces. Looks good, then.
Previous Comments:
[2010-04-13 16:52:49] degeb...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
When someone receives an instance of a One object, the method signature
of foo() tells them that it needs an IOne instance. In Two you further
restrict that to an ITwo. Seeing as a Two instance is a One instance, a
Two instance will be accepted by people who want a One instance. They
cannot know that the parameter requirements have been changed and that
is why you get an E_STRICT.
Also, this is not just for interfaces, but for classes as well.
[2010-04-12 15:43:13] mike at mikegerwitz dot com
Description:
When using an interface for type hinting, PHP raises a strict standards
warning
if an overriding method uses an interface that implements the type hint.
In the
example below, ITwo implements IOne and method One::foo expects the
first
argument to implement IOne. Two extends One and expects the first
argument to
implement ITwo, which implements IOne. This should be allowed, much like
it is
allowed if the interfaces were simply classes.
Test script:
---
interface IOne {}
interface ITwo extends IOne {}
class One
{
public function foo( IOne $bla ) {}
}
class Two extends One
{
public function foo( ITwo $bla ) {}
}
class Test implements ITwo {}
// yet, this does work
var_dump( new Test instanceof IOne );
Expected result:
bool(true)
Actual result:
--
PHP Strict Standards: Declaration of Two::foo() should be compatible
with that
of One::foo() in test.php on line 25
Strict Standards: Declaration of Two::foo() should be compatible with
that of
One::foo() in test.php on line 25
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51542edit=1
[PHP-BUG] Bug #51542 [NEW]: Overriding method type hint with child interface raises strict standards
From:
Operating system: GNU/Linux
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Overriding method type hint with child interface raises strict
standards
Description:
When using an interface for type hinting, PHP raises a strict standards
warning
if an overriding method uses an interface that implements the type hint. In
the
example below, ITwo implements IOne and method One::foo expects the first
argument to implement IOne. Two extends One and expects the first argument
to
implement ITwo, which implements IOne. This should be allowed, much like it
is
allowed if the interfaces were simply classes.
Test script:
---
interface IOne {}
interface ITwo extends IOne {}
class One
{
public function foo( IOne $bla ) {}
}
class Two extends One
{
public function foo( ITwo $bla ) {}
}
class Test implements ITwo {}
// yet, this does work
var_dump( new Test instanceof IOne );
Expected result:
bool(true)
Actual result:
--
PHP Strict Standards: Declaration of Two::foo() should be compatible with
that
of One::foo() in test.php on line 25
Strict Standards: Declaration of Two::foo() should be compatible with that
of
One::foo() in test.php on line 25
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=51542edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51542r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51542r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51542r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51542r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51542r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51542r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51542r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51542r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51542r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51542r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51542r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51542r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51542r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51542r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51542r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51542r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51542r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51542r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51542r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51542r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51542r=mysqlcfg
#48971 [NEW]: ZEND_NS_* Macros
From: mike at mikegerwitz dot com
Operating system: GNU/Linux
PHP version: 5.3.0
PHP Bug Type: *General Issues
Bug description: ZEND_NS_* Macros
Description:
PHP 5.3 seems to have missed a few things internally (macro-wise) when it
comes to namespaces. When developing an extension for 5.3, I noticed the
following:
Zend/zend_API.h:93
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info)
It's blank! I do not see any options to submit patches, therefore, this
should be the definition:
#define ZEND_NS_NAMED_FE(ns, zend_name, name, arg_info) \
ZEND_NS_FENTRY(ns, zend_name, name, arg_info, 0)
In addition, PHP_NS_* aliases are missing for the ZEND_NS_* macros. For
example, PHP_FE is an alias to ZEND_FE. Therefore, the following macros
should be added:
#define PHP_NS_FE ZEND_NS_FE
#define PHP_NS_NAMED_FE ZEND_NS_NAMED_FE
#define PHP_NS_DEP_FE ZEND_NS_DEP_FE
#define PHP_NS_FALIAS ZEND_NS_FALIAS
#define PHP_NS_DEP_FALIAS ZEND_NS_DEP_FALIAS
If you could provide me with a means to submit a patch, I would be more
than happy to do it myself, as I feel this to be an important (albeit
minor) addition for extension developers in order to keep things
consistent, and less confusing.
Reproduce code:
---
zend_function_entry php_test_functions[] = {
ZEND_NS_NAMED_FE( Ns, myfunc, test_myfunc, NULL )
{ NULL, NULL, NULL }
};
---
?php var_dump( get_extension_funcs('test') ); ?
Expected result:
array(1) {
[0]=
string(16) Ns\myfunc
}
Actual result:
--
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=48971edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48971r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48971r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48971r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=48971r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=48971r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48971r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48971r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48971r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48971r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48971r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48971r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48971r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48971r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48971r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48971r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48971r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48971r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48971r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48971r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48971r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48971r=mysqlcfg
#46634 [NEW]: Array key differentiates between unicode and binary strings
From: mike at mikegerwitz dot com Operating system: GNU/Linux PHP version: 6CVS-2008-11-20 (snap) PHP Bug Type: Arrays related Bug description: Array key differentiates between unicode and binary strings Description: Array keys in PHP 6 differentiate between unicode and binary strings - that is, a unicode key of 'test' is entirely different than a binary key of 'test'. Reproduce code: --- $arr = array(); $arr[ (unicode)'test' ] = 'unicode'; $arr[ (binary)'test' ] = 'binary'; // If unicode semantics is enabled, this will output 'unicode' var_dump( $arr['test'] ); // Will output 'binary' var_dump( $arr[ b'test'] ); // Will output 'unicode' var_dump( $arr[ (unicode)'test' ] ); Expected result: All three lines should output 'binary' unicode(7) binary unicode(6) binary unicode(7) binary Actual result: -- unicode(7) unicode unicode(6) binary unicode(7) unicode -- Edit bug report at http://bugs.php.net/?id=46634edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46634r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46634r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46634r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46634r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46634r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46634r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46634r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46634r=needscript Try newer version: http://bugs.php.net/fix.php?id=46634r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46634r=support Expected behavior: http://bugs.php.net/fix.php?id=46634r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46634r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46634r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46634r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46634r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46634r=dst IIS Stability: http://bugs.php.net/fix.php?id=46634r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46634r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46634r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46634r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46634r=mysqlcfg
#45585 [Com]: fread() return value for EOF inconsistent between PHP 5 and 6
ID: 45585
Comment by: mike at mikegerwitz dot com
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: *
PHP Version: 6CVS-2008-07-21 (CVS)
New Comment:
Confirmed in php6.0-200810110430. Cannot reliably loop through data
using feof() when recognizing FALSE as an error.
while ( !( feof( $handle ) ) )
{
if ( ( $text = fread( $handle, 1024 ) ) === FALSE )
{
// When attempting to read past the EOF, PHP 6 returns FALSE
rather than an empty string
die( 'Error!' );
}
$data .= $text;
}
In PHP 6, the above code will not display the error. In PHP 6, it
does a good job of breaking a lot of code. Is this new functionality
intended or are there plans to fix it?
Previous Comments:
[2008-07-21 16:34:04] [EMAIL PROTECTED]
In 5.2/5.3 it returns empty string, in PHP 6 FALSE.
[2008-07-21 16:33:34] [EMAIL PROTECTED]
Description:
# echo 1 /tmp/test.txt
# php_5_2/sapi/cli/php -n -r '$fp=fopen(/tmp/test.txt, r); while(1)
{$a=fread($fp, 8192); if (!$a) {var_dump($a); exit;}}'
string(0)
# php_5_3/sapi/cli/php -n -r '$fp=fopen(/tmp/test.txt, r); while(1)
{$a=fread($fp, 8192); if (!$a) {var_dump($a); exit;}}'
string(0)
# php_6/sapi/cli/php -n -r '$fp=fopen(/tmp/test.txt, r); while(1)
{$a=fread($fp, 8192); if (!$a) {var_dump($a); exit;}}'
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=45585edit=1
