date:20120818

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

2012-08-18 Thread rasmus

Edit report at https://bugs.php.net/bug.php?id=62861&edit=1

 ID: 62861
 Updated by: ras...@php.net
 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 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.


Previous Comments:

[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  tag in that  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) . In UTF-8 the copyright symbol is 
represented by two bytes, . 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 "©" 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 
©), 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:
---


Expected result:

©

Actual result:
--
(Nothing - an empty string)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62861&edit=1

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

2012-08-18 Thread soapergem at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=62861&edit=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  tag in that  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) . In UTF-8 the copyright symbol is 
represented by two bytes, . 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 "©" 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 
©), 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:
---


Expected result:

©

Actual result:
--
(Nothing - an empty string)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62861&edit=1

Bug #62861 [Opn->Nab]: htmlentities returns empty string when it shouldn't

2012-08-18 Thread rasmus

Edit report at https://bugs.php.net/bug.php?id=62861&edit=1

 ID: 62861
 Updated by: ras...@php.net
 Reported by:soapergem at gmail dot com
 Summary:htmlentities returns empty string when it shouldn't
-Status: Open
+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:

UTF-8 is only compatible with low-ascii, not with high. The copyright symbol in 
ISO-8859-1 is character code (in hex) . In UTF-8 the copyright symbol is 
represented by two bytes, . 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 "©" 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.


Previous Comments:

[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 
©), 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:
---


Expected result:

©

Actual result:
--
(Nothing - an empty string)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62861&edit=1

[PHP-BUG] Bug #62861 [NEW]: htmlentities returns empty string when it shouldn't

2012-08-18 Thread soapergem at gmail dot com

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
©), 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:
---


Expected result:

©

Actual result:
--
(Nothing - an empty string)

-- 
Edit bug report at https://bugs.php.net/bug.php?id=62861&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62861&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62861&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62861&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62861&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62861&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62861&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62861&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62861&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62861&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62861&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62861&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62861&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62861&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62861&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62861&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62861&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62861&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62861&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62861&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62861&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62861&r=mysqlcfg

[PHP-BUG] Req #62860 [NEW]: Moar magic methods! constructStatic(), getStatic(), setStatic(), get

2012-08-18 Thread michaelduff2 at yahoo dot com

From: michaelduff2 at yahoo dot com
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Moar magic methods! __constructStatic(), __getStatic(), 
__setStatic(), __get

Description:

__constructStatic() - executed automatically on class definition

__getStatic() - executed when ClassName::$inaccessible_property is fetched

__setStatic() - executed when ClassName::$inaccessible_property is
modified


The particular use case I have for this is self-loading configuration
registry singletons:



Currently, I accomplish this with __callStatic() which needs the extra
open-close parenthesis.  Ideally, we could get rid of the '$' too, but that
would need some __getConst() magic, which is just madness.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62860&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62860&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62860&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62860&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62860&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62860&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62860&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62860&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62860&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62860&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62860&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62860&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62860&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62860&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62860&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62860&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62860&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62860&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62860&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62860&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62860&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62860&r=mysqlcfg

Bug #61009 [Com]: max_input_vars

2012-08-18 Thread jdeluca2000 at kellogg dot northwestern dot edu

Edit report at https://bugs.php.net/bug.php?id=61009&edit=1

 ID: 61009
 Comment by: jdeluca2000 at kellogg dot northwestern dot edu
 Reported by:j dot hensoldt at gmx dot de
 Summary:max_input_vars
 Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Debian squeeze
 PHP Version:5.3SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Hello, can you explain how you were able to change the max_input_vars 
directive?  
Exactly which file did you edit and what is the code needed to change it to 
something other than 1,000?


Previous Comments:

[2012-02-10 11:11:21] j dot hensoldt at gmx dot de

SOLVED :-)

It was suhosin. The parameters:

suhosin.get.max_vars
suhosin.post.max_vars 
suhosin.request.max_vars

overwrite max_input_vars in php.ini.
ThatÂ´s confused.


[2012-02-08 13:37:04] j dot hensoldt at gmx dot de

ok, max_input_vars cantÂ´t be set using ini_set().  I did not know that - 
thanks.

But i cantÂ´t set max_input_vars in php.ini too. phpinfo() displays the 
correctly changed value (for example max_input_vars=5000), but the 
array-input-variables with index > 1000 are truncated. (sorry for my english, i 
hope you can understand me)


[2012-02-08 13:14:26] ahar...@php.net

As http://au2.php.net/manual/en/info.configuration.php says, max_input_vars is 
PHP_INI_PERDIR, so can't be set with ini_set().


[2012-02-08 13:00:06] j dot hensoldt at gmx dot de

Description:

I am using PHP 5.3.3-7+squeeze7 on Debian+Apache2.

I cannÂ´t change the parameter max_input_vars.



A change of max_input_vars in php.ini does not work too. phpinfo() displays the 
correctly changed value, but the internal value of max_input_vars is not 
changed and is always 1000.








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61009&edit=1

[PHP-BUG] Req #62859 [NEW]: Give __construct() the respect it deserves

2012-08-18 Thread michaelduff2 at yahoo dot com

From: michaelduff2 at yahoo dot com
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Give __construct() the respect it deserves 

Description:

Here's a PHP6 -- or PHP7 ;) request for you; many will scream
N, but hear me out:

Make it possible to return an object from __construct().

Yeah, I said it. Sounds crazy, but this would make factories more abstract,
and enables all sorts of magic without user code being any wiser (unless
they Reflect upon it, I suppose.)

For type safety, the object returned should probably be an instanceof
__CLASS__.

If no return() exists, then normal 'new' semantics would apply.

Discuss.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62859&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62859&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62859&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62859&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62859&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62859&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62859&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62859&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62859&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62859&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62859&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62859&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62859&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62859&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62859&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62859&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62859&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62859&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62859&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62859&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62859&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62859&r=mysqlcfg

[PHP-BUG] Req #62858 [NEW]: Please remove 'final' restriction on SimpleXMLElement::__construct

2012-08-18 Thread michaelduff at yahoo dot com

From: michaelduff at yahoo dot com
Operating system: 
PHP version:  5.4.6
Package:  SimpleXML related
Bug Type: Feature/Change Request
Bug description:Please remove 'final' restriction on 
SimpleXMLElement::__construct

Description:

The __construct() method on SimpleXMLElement is marked 'final', which
prevents extension of the class for, say, XML-format-specific objects which
augment otherwise empty incoming XML data.

The current workaround is to use __get and __set and company (which
unfortunately means  fails), and
which is much slower -- or to use a static factory method which forces some
XML in there (which is syntactically ugly imo.)

Not to shoot my request in the foot, but I forsee possible issues with
these functions:

- simplexml_import_dom ( $node [, $class_name ] )
- simplexml_load_file ( string $filename [, string $class_name ] ... )
- simplexml_load_string ( string $data [, string $class_name ] ... )

However, perhaps it would suffice to require 'a compatible function
signature' rather than to mark it final?


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62858&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62858&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62858&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62858&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62858&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62858&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62858&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62858&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62858&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62858&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62858&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62858&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62858&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62858&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62858&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62858&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62858&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62858&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62858&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62858&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62858&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62858&r=mysqlcfg

[PHP-BUG] Bug #62857 [NEW]: bytea test failures

2012-08-18 Thread ni...@php.net

From: nikic
Operating system: 
PHP version:  master-Git-2012-08-18 (Git)
Package:  PostgreSQL related
Bug Type: Bug
Bug description:bytea test failures

Description:

The following bytea related tests are currently failing for me (and on
travis):

https://qa.php.net/reports/viewreports.php?version=5.5.0-dev&test=%2Fext%2Fpgsql%2Ftests%2F12pg_insert_85.phpt
https://qa.php.net/reports/viewreports.php?version=5.5.0-dev&test=%2Fext%2Fpgsql%2Ftests%2F14pg_update_85.phpt
https://qa.php.net/reports/viewreports.php?version=5.5.0-dev&test=%2Fext%2Fpgsql%2Ftests%2F10pg_convert_85.phpt
https://qa.php.net/reports/viewreports.php?version=5.5.0-dev&test=%2Fext%2Fpgsql%2Ftests%2F18pg_escape_bytea.phpt

It seems to be some kind of change in the escaping format (double backslash
vs single backslash).

I don't use pgsql, so I can't tell whether this is a bug or just an
out-of-date test. Would be nice if someone could have a look at this.

If it helps, here are the docs for binary escape formats:
http://www.postgresql.org/docs/devel/static/datatype-binary.html


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62857&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62857&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62857&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62857&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62857&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62857&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62857&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62857&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62857&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62857&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62857&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62857&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62857&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62857&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62857&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62857&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62857&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62857&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62857&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62857&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62857&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62857&r=mysqlcfg

Bug #62854 [Nab]: Segfault on call_user_func_array

2012-08-18 Thread popsul1993 at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=62854&edit=1

 ID: 62854
 User updated by:popsul1993 at gmail dot com
 Reported by:popsul1993 at gmail dot com
 Summary:Segfault on call_user_func_array
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Why that not a bug? Interpreter crashes when recursion is over 
call_user_func_array, and necessary make Fatal Error. IF that code running 
under 
php 5.3 - behavior is correct, and under 5.4 - interpreter crash with segfault.

p.s. Sorry for my English.


Previous Comments:

[2012-08-18 15:13:21] fel...@php.net

.


[2012-08-18 14:21:34] popsul1993 at gmail dot com

> Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of 
ActiveRecord 
> have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql();
> that call send to __call(), where there is a checing with code 
> method_exists($this, $method_name), which returning true and after that 
calling 
> call_user_func_array([$this, $method_name], $parameters);, and that 
> invocation 
> again sending to __call(), although method buildSql exists and visibled.

that bug already resolved and fixed, autoreplace error. sorry.


[2012-08-18 14:07:27] popsul1993 at gmail dot com

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql' 
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql(); that call send to __call(), where there is a checing with code 
method_exists($this, $method_name), which returning true and after that calling 
call_user_func_array([$this, $method_name], $parameters);, and that invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test->foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0, 
fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=, 
error=0xbf8000f4, spec=, va=0xbf800158, arg=0xb70ad254, 
arg_num=) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a "fa/", va=0xbf800158, 
flags=0) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a "fa/") 
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#8  0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#9  0x08336060 in zend_call_function (fci=0xbf8003a0, fci_cache=0xbf8003c4) at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#10 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd310, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4

Bug #62854 [Opn->Nab]: Segfault on call_user_func_array

2012-08-18 Thread felipe

Edit report at https://bugs.php.net/bug.php?id=62854&edit=1

 ID: 62854
 Updated by: fel...@php.net
 Reported by:popsul1993 at gmail dot com
 Summary:Segfault on call_user_func_array
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

.


Previous Comments:

[2012-08-18 14:21:34] popsul1993 at gmail dot com

> Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of 
ActiveRecord 
> have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql();
> that call send to __call(), where there is a checing with code 
> method_exists($this, $method_name), which returning true and after that 
calling 
> call_user_func_array([$this, $method_name], $parameters);, and that 
> invocation 
> again sending to __call(), although method buildSql exists and visibled.

that bug already resolved and fixed, autoreplace error. sorry.


[2012-08-18 14:07:27] popsul1993 at gmail dot com

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql' 
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql(); that call send to __call(), where there is a checing with code 
method_exists($this, $method_name), which returning true and after that calling 
call_user_func_array([$this, $method_name], $parameters);, and that invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test->foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0, 
fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=, 
error=0xbf8000f4, spec=, va=0xbf800158, arg=0xb70ad254, 
arg_num=) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a "fa/", va=0xbf800158, 
flags=0) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a "fa/") 
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#8  0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#9  0x08336060 in zend_call_function (fci=0xbf8003a0, fci_cache=0xbf8003c4) at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#10 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd310, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4749
#11 0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#12 0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#13 0x08336060 in zend_call_function (fci=0xbf8005b0, fci_cache=0xbf8005d4) at 
/home/popsul/ÐÐ°Ð³Ñ

Bug #62854 [Opn]: Segfault on call_user_func_array

2012-08-18 Thread popsul1993 at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=62854&edit=1

 ID: 62854
 User updated by:popsul1993 at gmail dot com
 Reported by:popsul1993 at gmail dot com
 Summary:Segfault on call_user_func_array
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

> Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of 
ActiveRecord 
> have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql();
> that call send to __call(), where there is a checing with code 
> method_exists($this, $method_name), which returning true and after that 
calling 
> call_user_func_array([$this, $method_name], $parameters);, and that 
> invocation 
> again sending to __call(), although method buildSql exists and visibled.

that bug already resolved and fixed, autoreplace error. sorry.


Previous Comments:

[2012-08-18 14:07:27] popsul1993 at gmail dot com

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql' 
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql(); that call send to __call(), where there is a checing with code 
method_exists($this, $method_name), which returning true and after that calling 
call_user_func_array([$this, $method_name], $parameters);, and that invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test->foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0, 
fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=, 
error=0xbf8000f4, spec=, va=0xbf800158, arg=0xb70ad254, 
arg_num=) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a "fa/", va=0xbf800158, 
flags=0) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a "fa/") 
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#8  0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#9  0x08336060 in zend_call_function (fci=0xbf8003a0, fci_cache=0xbf8003c4) at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#10 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd310, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4749
#11 0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#12 0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#13 0x08336060 in zend_call_function (fci=0xbf8005b0, fci_cache=0xbf8005d4) at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#14 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd194, 
return_value_ptr=0x0,

[PHP-BUG] Bug #62854 [NEW]: Segfault on call_user_func_array

2012-08-18 Thread popsul1993 at gmail dot com

From: popsul1993 at gmail dot com
Operating system: Ubuntu 12.04
PHP version:  5.4.6
Package:  Reproducible crash
Bug Type: Bug
Bug description:Segfault on call_user_func_array

Description:

PHP crash through deep nested recursion over call_user_func_array


Compilation config:
./configure '--enable-fpm' '--enable-mbstring' '--with-mysql'
'--with-regex=php' 
'--with-tidy=shared' '--prefix=/usr/local/' --with-config-file-scan-
dir=/usr/local/etc/php5

Also, PHP >=5.4.5 have a crazy behavior, i.e. my implementation of
ActiveRecord 
have method 'buildSql' (with public visibility), but when run e.g. $this-
>buildSql(); that call send to __call(), where there is a checing with code

method_exists($this, $method_name), which returning true and after that
calling 
call_user_func_array([$this, $method_name], $parameters);, and that
invocation 
again sending to __call(), although method buildSql exists and visibled.


Test script:
---
class Test {
public function foo() {
return call_user_func_array([$this, 'foo'], func_get_args());
}
}

$test = new Test();
$test->foo();

Actual result:
--
(gdb) run
Starting program: /usr/local/bin/php -e ./tests/testrecursion.php

Program received signal SIGSEGV, Segmentation fault.
zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
2970if 
(zend_hash_num_elements(Z_ARRVAL_P(callable)) == 2) {
(gdb) backtrace
#0  zend_is_callable_ex (callable=0xb70bd424, object_ptr=, 
check_flags=0, callable_name=0x0, callable_name_len=0xbf80, 
fcc=0xbf8001b4, error=0xbf800108) at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:2970
#1  0x0834a89f in zend_fcall_info_init (callable=0xb70bd424, check_flags=0,

fci=0xbf800190, fcc=0xbf8001b4, callable_name=0x0, error=0xbf800108)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:3126
#2  0x0834af0a in zend_parse_arg_impl (severity=, 
error=0xbf8000f4, spec=, va=0xbf800158, arg=0xb70ad254,

arg_num=) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-
5.4.6/Zend/zend_API.c:616
#3  zend_parse_arg (quiet=0, spec=, va=0xbf800158, 
arg=0xb70ad254, arg_num=1)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:675
#4  zend_parse_va_args (num_args=1, type_spec=0x878128a "fa/",
va=0xbf800158, 
flags=0) at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:844
#5  0x0834c6d2 in zend_parse_parameters (num_args=2, type_spec=0x878128a
"fa/") 
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_API.c:895
#6  0x08256b77 in zif_call_user_func_array (ht=2, return_value=0xb70bd48c,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4742
#7  0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#8  0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#9  0x08336060 in zend_call_function (fci=0xbf8003a0, fci_cache=0xbf8003c4)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#10 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd310,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4749
#11 0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#12 0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#13 0x08336060 in zend_call_function (fci=0xbf8005b0, fci_cache=0xbf8005d4)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#14 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd194,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4749
#15 0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#16 0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:410
#17 0x08336060 in zend_call_function (fci=0xbf8007c0, fci_cache=0xbf8007e4)
at 
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_execute_API.c:958
#18 0x08256ba0 in zif_call_user_func_array (ht=2, return_value=0xb70bd018,

return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/ext/standard/basic_functions.c:4749
#19 0x083df418 in zend_do_fcall_common_helper_SPEC (execute_data=)
at /home/popsul/ÐÐ°Ð³ÑÑÐ·ÐºÐ¸/php-5.4.6/Zend/zend_vm_execute.h:642
#20 0x083a242d in execute (op_array=) at /home/popsul/
ÐÐ°Ð³ÑÑ

[PHP-BUG] Req #62853 [NEW]: Support for parsing vlv control response

2012-08-18 Thread vanmeeuwen at kolabsys dot com

From: vanmeeuwen at kolabsys dot com
Operating system: Linux
PHP version:  5.4.6
Package:  LDAP related
Bug Type: Feature/Change Request
Bug description:Support for parsing vlv control response

Description:

A Virtual List View control response includes the total number of entries
in the virtual list view used.

An additional function is needed to get to that response, and be able to
efficiently list a properly paginated ($1 to $2 entries of $3 total) LDAP
directory information tree.

Test script:
---
Example use of this new function can be found at, for example;

 
https://github.com/roundcube/roundcubemail/blob/master/program/include/rcube_ldap.php#L1409

  http://git.kolab.org/pear/Net_LDAP3/tree/lib/Net/LDAP3.php#n728


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62853&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62853&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62853&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62853&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62853&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62853&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62853&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62853&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62853&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62853&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62853&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62853&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62853&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62853&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62853&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62853&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62853&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62853&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62853&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62853&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62853&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62853&r=mysqlcfg

[PHP-BUG] Bug #62852 [NEW]: Unserialize Invalid Date causes crash

2012-08-18 Thread kasper at webmasteren dot eu

From: kasper at webmasteren dot eu
Operating system: windows, linux
PHP version:  Irrelevant
Package:  Reproducible crash
Bug Type: Bug
Bug description:Unserialize Invalid Date causes crash

Description:

Core PHP,every version so far, 5.3.* and 5.4.*
When unserializing this string :
O:8:"DateTime":3:{s:4:"date";s:20:"10007-06-07 
03:51:49";s:13:"timezone_type";i:3;s:8:"timezone";s:3:"UTC";}
created from: Datetime:createFromFormat("99-99-","j-n-Y");
then serialized, to a file. Later when read and working with, php crashes,
from 
the parse_tz.c, in timelib_get_time_zone_info. the Exception is "read at
offset 
0x0010". it would appear that ts and / or tz is zero. 


Test script:
---
$temp =  unserialize('O:8:"DateTime":3:{s:4:"date";s:20:"10007-06-07
03:51:49";s:13:"timezone_type";i:3;s:8:"timezone";s:3:"UTC";}');
var_dump($temp);

Expected result:

error parsing invalid date or just a date with all entries 0.

Actual result:
--
php crash [read offset 0x0010] ~  null pointer + offset. at the file 
"ext\date\lib\parse_tz.c"

-- 
Edit bug report at https://bugs.php.net/bug.php?id=62852&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62852&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62852&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62852&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62852&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62852&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62852&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62852&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62852&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62852&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62852&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62852&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62852&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62852&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62852&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62852&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62852&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62852&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62852&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62852&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62852&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62852&r=mysqlcfg

Bug #62818 [Wfx]: $_SERVER['PHP_SELF'] problem

2012-08-18 Thread ciropellegrino at libero dot it

Edit report at https://bugs.php.net/bug.php?id=62818&edit=1

 ID: 62818
 User updated by:ciropellegrino at libero dot it
 Reported by:ciropellegrino at libero dot it
 Summary:$_SERVER['PHP_SELF'] problem
 Status: Wont fix
 Type:   Bug
 Package:Built-in web server
 Operating System:   Windows 7
 PHP Version:5.4.5
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Thanks for the explanation. 
I'm sorry for the false alarm.

Bye


Previous Comments:

[2012-08-17 12:44:00] larue...@php.net

this behavior act the same as other webserver which supports PATH_INFO like 
apache


[2012-08-14 15:12:45] ciropellegrino at libero dot it

Description:

An extra character / is inserted in the superglobal $_SERVER['PHP_SELF']

Test script:
---


Expected result:

/index.php

Actual result:
--
/index.php/






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62818&edit=1

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

Bug #62861 [Nab]: htmlentities returns empty string when it shouldn't

Bug #62861 [Opn->Nab]: htmlentities returns empty string when it shouldn't

[PHP-BUG] Bug #62861 [NEW]: htmlentities returns empty string when it shouldn't

[PHP-BUG] Req #62860 [NEW]: Moar magic methods! constructStatic(), getStatic(), setStatic(), get

Bug #61009 [Com]: max_input_vars

[PHP-BUG] Req #62859 [NEW]: Give __construct() the respect it deserves

[PHP-BUG] Req #62858 [NEW]: Please remove 'final' restriction on SimpleXMLElement::__construct

[PHP-BUG] Bug #62857 [NEW]: bytea test failures

Bug #62854 [Nab]: Segfault on call_user_func_array

Bug #62854 [Opn->Nab]: Segfault on call_user_func_array

Bug #62854 [Opn]: Segfault on call_user_func_array

[PHP-BUG] Bug #62854 [NEW]: Segfault on call_user_func_array

[PHP-BUG] Req #62853 [NEW]: Support for parsing vlv control response

[PHP-BUG] Bug #62852 [NEW]: Unserialize Invalid Date causes crash

Bug #62818 [Wfx]: $_SERVER['PHP_SELF'] problem

16 matches

Site Navigation

Mail list logo

Footer information