Req #46506 [Opn]: readonly attribute for (public) class variables

2012-01-25 Thread glideraerobatics at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=46506edit=1

 ID: 46506
 User updated by:glideraerobatics at hotmail dot com
 Reported by:glideraerobatics at hotmail dot com
 Summary:readonly attribute for (public) class variables
 Status: Open
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
-PHP Version:5.3.0alpha2
+PHP Version:5.4
 Block user comment: N
 Private report: N

 New Comment:

Changed affected PHP version.


Previous Comments:

[2012-01-24 23:12:32] luke at cywh dot com

I just want the readonly keyword to protect a property from being written to 
from the outside. I still want to write to the property from within the class.

Here's a simple example of how it could be used:

class Parent
{
readonly public $children = array();

public function addChild($childName)
{
$this-children[] = ucwords(strtolower($childName));
}
}

$parent = new Parent;
$parent-addChild(billy);

$count = count($parent-children); // You can do this

print Parent has $count children\n;

$name = $parent-children[0]; // You can even do this

print Parent's first child's name is $name\n;

$parent-children[0] = BILLY; // But you can't do this
$parent-children[] = BOB; // Or this
$parent-children = NULL; // Or this
unset($parent-children); // Or this


The above example frees you from having to do this:

class Parent
{
protected $children = array();

public function addChild($childName)
{
$this-children[] = ucwords(strtolower($childName));
}

public function hasChild($index)
{
return isset($this-children[$index]);
}

public function getChild($index)
{
return $this-children[$index];
}

public function childCount()
{
return count($this-children);
}
}


I've had to write MANY classes like this. The has/isset, get, and count 
functions are virtually all the same.

Some people have even resorted to using __get and __set:

http://stackoverflow.com/questions/402215/php-readonly-properties

The __get and __set magic functions are slow, so much so you're better off 
making your own getters and setters, which is multiplied by the number of 
properties you need like this in the class.

I would recommend the following definitions:

readonly public = read for public, write for protected
readonly protected = read for protected, write for private

I think this should satisfy most cases.


[2009-07-12 13:27:08] mickael at lupusmic dot org

I guess the readonly keyword in C# is wrong. It hasn't to disallow variance of 
the attribute, but the setting from outside the object. Readonly is opposite to 
constness of a variable. For example, DOMDocument::doctype isn't constant.

What you think about, it's a dynamic const attribute, in opposite to static one.

So said, a readonly is like a const attribute, but isn't. And it doesn't 
deserve a scope qualifier, it can only be public.

For example :

class thing
{
readonly$status = 'instantiation' ;

public  function __construct()
{
// do init stuff

$this-status = 'instantiate' ;
}

public  function invalidate()
{
// do stuf
$this-status = 'invalid' ;
}
}

// Usage
$o = new thing ;
echo $o-status ; // display 'instantiation'
$o-status = 'forced' ; // throw an error E_FATAL

$o-invalidate() ; // do stuff then set readonly status attribute


[2008-11-06 14:11:42] glideraerobatics at hotmail dot com

Description:

Here is a description of this feature in C#:
http://blog.paranoidferret.com/index.php/2007/09/12/csharp-tutorial-the-readonly-keyword/

In a nutshell it allows you to create classes with public variables that are 
readonly and can only be written to / initialized by the contructor of the 
class itself.

This allows the creation of simple objects without having using accessor 
methods to protect the internal data that was validated and initialized during 
construction from corruption.

Note: bug http://bugs.php.net/bug.php?id=39467 is about a similar problem but 
the proposed solution is not quite right.

Reproduce code:
---
class Person
{
  public readonly $name = null;
  public readonly $age = null;
  public readonly $weight = null;

  public function __construct($name, $age, $weight) {
  {
if (!isAgeToWeightRatioSane($age, $weight)) {
  throw new InvalidArgumentException(Invalid age to weight ratio: $age : 
$weight);
}
// TODO: other sanity checks here.
$this-name = $name;
$this-age = $age;
$this-weight = $weight;
  }
}


$person = new 

Bug #60701 [Opn]: __toString() which stores $this reference triggers segfault (with fix!)

2012-01-25 Thread daan at react dot com
Edit report at https://bugs.php.net/bug.php?id=60701edit=1

 ID: 60701
 User updated by:daan at react dot com
 Reported by:daan at react dot com
-Summary:__toString() which stores $this reference triggers
 segfault
+Summary:__toString() which stores $this reference triggers
 segfault (with fix!)
 Status: Open
 Type:   Bug
-Package:Class/Object related
+Package:Reproducible crash
 Operating System:   CentOS
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Working patch fix now included! (tm)


Previous Comments:

[2012-01-20 13:28:42] hans at rakers dot org

This bug is caused by zend_std_cast_object_tostring() not checking the refcount 
of readobj when readobj==writeobj. It calls INIT_PZVAL(writeobj) without 
checking the refcount first, causing any further references to this zval to get 
corrupted (in this case, the 'test' property of StringableObject).

My patch against 5.3 is attached.


[2012-01-10 19:22:39] sjon at hortensius dot net

This bug is not reproducible when php is compiled with enable-debug. It is 
however reproducible in other PHP versions, such as 5.3.7/5.3.6/5.3.5


[2012-01-10 16:43:17] daan at react dot com

Description:

A simple object construction where a __toString() stores $this, will trigger a 
segfault during garbage collection at the end of the request.

Probably related bug: https://bugs.php.net/bug.php?id=60598
Is a distilled version of this bug: https://bugs.php.net/bug.php?id=60457

Test script:
---
?php
class Container
{
public function getObject()
{
$this-object = new StringableObject();

return $this-object;
}

// This destructor is required to exist to trigger the segfault
public function __destruct()
{
}
}

class StringableObject
{
public function __toString()
{
$this-test = $this;

return '';
}
}

$container = new Container();
$object = $container-getObject();

// Any kind of function which triggers a 'to string' object conversion
// Casting $object with (string) will circumvent the problem
echo trim($object);
// Another call is required to corrupt heap
echo trim('test');


Expected result:

test

Actual result:
--
Segfault

gdb backtrace (with commandline PHP with build tag ZEND_DEBUG_OBJECTS)

[Thread debugging using libthread_db enabled]
Allocated object id #1
Allocated object id #2
Increased refcount of object id #2
Decreased refcount of object id #2
testIncreased refcount of object id #1
Decreased refcount of object id #1
Deallocated object id #1

Program received signal SIGSEGV, Segmentation fault.
0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_gc.c:143
143GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at 
/home/sjon/php-debug/php-5.3.8/Zend/zend_gc.c:143
#1  0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
#2  0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at 
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
#3  0x006d6029 in zend_objects_free_object_storage (object=0x1023dc8) 
at 
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:126
#4  0x006da037 in zend_objects_store_del_ref_by_handle_ex (handle=2, 
handlers=optimized out) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_objects_API.c:220
#5  0x006da053 in zend_objects_store_del_ref (zobject=0x1022350) at 
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:172
#6  0x006a9571 in _zval_dtor (zvalue=0x1022350) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_variables.h:35
#7  _zval_ptr_dtor (zval_ptr=optimized out) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:447
#8  0x006c3645 in zend_hash_apply_deleter (ht=0xe33188, p=0x1026728) at 
/home/sjon/php-debug/php-5.3.8/Zend/zend_hash.c:612
#9  0x006c4f81 in zend_hash_reverse_apply (ht=0xe33188, 
apply_func=0x6a9430 zval_call_destructor) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_hash.c:762
#10 0x006a9921 in shutdown_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:226
#11 0x006b7747 in zend_call_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend.c:875
#12 0x006651fd in php_request_shutdown (dummy=optimized out) at 
/home/sjon/php-debug/php-5.3.8/main/main.c:1594
#13 0x0042d105 in main (argc=2, argv=0x7fffebb8) at /home/sjon/php-

[PHP-BUG] Bug #60876 [NEW]: max_input_vars corrupt posted data

2012-01-25 Thread jiri dot reischig at ecn dot cz
From: 
Operating system: 
PHP version:  5.3.9
Package:  *General Issues
Bug Type: Bug
Bug description:max_input_vars corrupt posted data

Description:

When you post some data to the php script where are more variables than
limit in max_input_vars the php script does not get any information that
php don't put any of data to the system variables (for example
$_REQUEST[]).
There is only PHP Warning generated but the php script is still running
without any problem with corrupted dataset from post.

Solution will be to stop executing the script if max_input_vars is
reached.

Without stoping the script you are working with currupted dataset and you
can make some data inconsistencies in your aplication without any
knowledge.

Test script:
---
max_input_vars = 1

sending post: test.php?a=1b=2c=3

print_r($_REQUEST);

Expected result:

Stop the script if max_input_vars is reached.


Actual result:
--
Array
(
[a] = 1
)

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



Bug #60668 [Com]: Setting user_agent can send other headers

2012-01-25 Thread me at ktamura dot com
Edit report at https://bugs.php.net/bug.php?id=60668edit=1

 ID: 60668
 Comment by: me at ktamura dot com
 Reported by:vr...@php.net
 Summary:Setting user_agent can send other headers
 Status: Open
 Type:   Bug
 Package:HTTP related
 Operating System:   Irrelevant
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

vrana: I think this is a pretty bad security issue. Here is a proposed diff as 
a 
github gist: https://gist.github.com/1675788


Previous Comments:

[2012-01-06 10:08:41] vr...@php.net

Description:

Setting 'user_agent' INI value to a string containing a newline causes sending 
a new header. This behavior is even documented: 
http://php.net/wrappers.http#wrappers.http.example.custom.headers

It is wrong for two reasons:

1. 'user_agent' INI setting should be used only for setting a User-Agent header 
and not for anything else.

2. It is a potential security risk (header injection) similar to the one fixed 
in PHP 5.1.2 (but with low impact).

(See also bug #52979 but I believe that I am providing a better reasoning.)

Test script:
---
?php
$_POST['user_agent'] = Robot\r\nX-Command: delete-all;
ini_set('user_agent', $_POST['user_agent']);
readfile('http://private/service.php');
?


Expected result:

Sending just a User-Agent header, not X-Command header.

Actual result:
--
Sending User-Agent and X-Command headers.

If http://private/service.php accepts connections only from trusted sources and 
parses its commands from headers then it will execute the malicious action.






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


Req #26411 [Com]: while {} else {}

2012-01-25 Thread hawkyhawk14 at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=26411edit=1

 ID: 26411
 Comment by: hawkyhawk14 at gmail dot com
 Reported by:php at bellytime dot com
 Summary:while {} else {}
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

This is a great idea. I am currently needing something like this, but however 
got 
around it using flags and making the flag true in the while. It would be alot 
more 
convenient if there was an else!

Please add this feature!!!


Previous Comments:

[2011-12-06 16:31:22] absimu at hotmail dot com

I agree. I think a while () else () will make things easier. I was researching 
and 
found out that it doesnt exist yet. 


while($row = mysqli_fetch_assoc($result)) { }

with al else I would fix it.. I am new in PHP,. I will try to find something to 
fix it. but if the while else is release in a new version that would be nice.


[2011-02-18 01:14:34] ijrbiz at gmail dot com

Highly agreed, this request would be very practical for improved coding 
structure and 
follows logical language syntax nicely.

function remove_items ($arr, $needle) {
while ($key = array_search($needle, $arr)) {
unset( $arr[$key] );
} else return false; // No items present
return true; // Item(s) removed
}


[2010-12-19 13:08:30] trefighter2334 at aol dot com

I'd love to see something like Python's while/else logic implemented in PHP.

This logical construct would allow developers to define blocks of code in else 
{} that'd run upon a natural exit from the while(){} loop caused by said loop's 
condition becoming FALSE; however, the else {} would be skipped over if the 
loop 
exits unnaturally -- a la through a break statement or because of an exception.

It is to die for on a semi-daily basis for me (in python)... but I'm not sure 
this is what the developers above (and their examples) have in mind or not.

Either implementation would prove useful to me.


[2008-04-09 07:51:11] ois at oisnot dot com

try {
  foreach ($nullValue as $nothing) {
echo 'valid input';
  } else {
//suppress notice
echo 'null value';
  }
  //or/and
} catch (ExceptionObjectNotIterator $e) {
  //object doesnt implement Iterator
  echo $e-getMessage();
}


[2003-11-29 08:59:16] elmi...@php.net

Yes, you're right, my code was wrong. Next try:

$found = false;
while ($row = mysql_fetch_assoc($result)) {
   $found = true;
   print 'Here is a result';
   ...
} 

if (!$found) {
   print 'No results found';
}


The proposed while/else syntax is indeed a bit more elegant.





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=26411


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


[PHP-BUG] Bug #60879 [NEW]: unserialize() Does not invoke __wakeup() on object

2012-01-25 Thread thijsputman at gmail dot com
From: 
Operating system: Windows 7
PHP version:  5.4.0RC6
Package:  Class/Object related
Bug Type: Bug
Bug description:unserialize() Does not invoke __wakeup() on object

Description:

When serializing/unserializing an object that contains both a __sleep() and
__wakeup() method, serialize() invokes the __sleep() method, but
unserialize() does *not* invoke the __wakeup() method.

Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which
did not exhibit this problem. See the below test script for an example
(which works as expected in RC5, but not in RC6).

Test script:
---
class Woei{

public function __sleep(){

echo 'sleep' . PHP_EOL;

return array();
}

public function __wakeup(){

echo 'wakeup' . PHP_EOL;
}
}

$Woei = new Woei();

$s1 = serialize($Woei);
$Woei2 = unserialize($s1);

$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);

Expected result:

sleep
wakeup
sleep
wakeup

Actual result:
--
sleep
sleep

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



[PHP-BUG] Bug #60881 [NEW]: readline detection fails because of rl_pending_input variable

2012-01-25 Thread lzsiga at freemail dot c3 dot hu
From: 
Operating system: aix
PHP version:  5.3.9
Package:  *Compile Issues
Bug Type: Bug
Bug description:readline detection fails because of rl_pending_input variable

Description:

Well, ./configure checks for function 'rl_pending_input', which happens to
be a variable. In AIX variables and functions are exported differently, so
the detection fails.

My quick fix:

sed_repl 's;rl_pending_input();rl_pending_input;g' configure


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



[PHP-BUG] Bug #60882 [NEW]: PDO crashes PHP FastCGI daemon when querying Sphinx server

2012-01-25 Thread balshoy dot tone at gmail dot com
From: 
Operating system: Ubuntu 11.10
PHP version:  5.4.0RC6
Package:  PDO related
Bug Type: Bug
Bug description:PDO crashes PHP FastCGI daemon when querying Sphinx server

Description:

I have a sphinx server with real time indexes and I'm trying to query them
using 
PDO via sphinx MySQL protocol.

Every time a script runs into `$pdo-execute(array(1))` part the whole PHP

FastCGI daemon crashes, no errors displayed in php error log.

Everything works normally when I query ordinary MySQL database this way.
Also provided code works fine in PHP 5.3

Test script:
---
$dsn = mysql:host=127.0.0.1;port=9306;dbname=index;
$pdo = new PDO($dsn, 'user', 'password'); 

$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = $pdo-prepare(SELECT * FROM user WHERE id = ?); 
$rslt = $stmt-execute(array(1)); // crash

var_dump($stmt-fetchAll(PDO::FETCH_ASSOC));

Expected result:

Either result set or PDO exception should be displayed.

Actual result:
--
Script fails silently without any records in error.log
Also PHP FastCGI daemon gets terminated.

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



[PHP-BUG] Bug #60883 [NEW]: php_intl crach

2012-01-25 Thread bugzilla33 at gmail dot com
From: 
Operating system: win 7
PHP version:  5.4.0RC6
Package:  Reproducible crash
Bug Type: Bug
Bug description:php_intl crach

Description:

1. use Apache 2.2.21 VC9
2. download
http://windows.php.net/downloads/qa/php-5.4.0RC6-Win32-VC9-x86.zip
3. unpack to c:\php5\
4. rename php.ini-development - php.ini
5. change php.ini:
   extension_dir = c:\php5\ext
   extension=php_intl.dll
6. restart apache
7. run any script


Test script:
---
any

Expected result:

no crash

Actual result:
--
crash

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



Bug #60883 [Com]: php_intl crach

2012-01-25 Thread bugzilla33 at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60883edit=1

 ID: 60883
 Comment by: bugzilla33 at gmail dot com
 Reported by:bugzilla33 at gmail dot com
 Summary:php_intl crach
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   win 7
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

testscript.php

?php
 phpinfo();
?


Previous Comments:

[2012-01-25 14:52:41] bugzilla33 at gmail dot com

Description:

1. use Apache 2.2.21 VC9
2. download http://windows.php.net/downloads/qa/php-5.4.0RC6-Win32-VC9-x86.zip
3. unpack to c:\php5\
4. rename php.ini-development - php.ini
5. change php.ini:
   extension_dir = c:\php5\ext
   extension=php_intl.dll
6. restart apache
7. run any script


Test script:
---
any

Expected result:

no crash

Actual result:
--
crash






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


Bug #53188 [Com]: php_date.c fails to compile (code line 499)

2012-01-25 Thread bobwei9 at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=53188edit=1

 ID: 53188
 Comment by: bobwei9 at hotmail dot com
 Reported by:jeremy dot iglehart at gmail dot com
 Summary:php_date.c fails to compile (code line 499)
 Status: Feedback
 Type:   Bug
 Package:Compile Failure
 Operating System:   Darwin (iPod OS4)
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Now the error is on line 500… with php 5.4 on ios5.0.1

Could you pelase fix this?


Previous Comments:

[2010-10-29 12:17:23] ahar...@php.net

Where did you source your toolchain from?

PHP does run on jailbroken iOS devices (the Telesphoreo repository has 5.2.8 
available), but I'd be surprised if that wasn't being cross-compiled off OS X 
via XCode.


[2010-10-28 03:14:58] jeremy dot iglehart at gmail dot com

Description:

I'm not sure why this is happening - and I can't find help from google or the 
IRC chatroom #php so I figured I would post it here.

For some reason I can't compile - when I try to run the compile I get this:

to get a full paste of it you can go here: http://pastebin.com/zTtsQiMX

Any idea?

Test script:
---
Here is a paste URL of the entire problem.
http://pastebin.com/zTtsQiMX

./configure code...

++
| License:   |
| This software is subject to the PHP License, available in this |
| distribution in the file LICENSE.  By continuing this installation |
| process, you are bound by the terms of this license agreement. |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point.|
++

Thank you for using PHP.

iPod-Touch:~/php-5.3.3 root# make
/bin/sh /var/root/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile 
gcc -Iext/date/lib -Iext/date/ -I/var/root/php-5.3.3/ext/date/ -DPHP_ATOM_INC 
-I/var/root/php-5.3.3/include -I/var/root/php-5.3.3/main -I/var/root/php-5.3.3 
-I/var/root/php-5.3.3/ext/date/lib -I/var/root/php-5.3.3/ext/ereg/regex 
-I/usr/include/libxml2 -I/usr/local/include 
-I/var/root/php-5.3.3/ext/sqlite3/libsqlite -I/var/root/php-5.3.3/TSRM 
-I/var/root/php-5.3.3/Zend  -no-cpp-precomp  -I/usr/include -g -O2  -c 
/var/root/php-5.3.3/ext/date/php_date.c -o ext/date/php_date.lo 
/var/root/php-5.3.3/ext/date/php_date.c:499: error: expected expression before 
'zend_date_globals'
/var/root/php-5.3.3/ext/date/php_date.c:499: error: initializer element is not 
constant
/var/root/php-5.3.3/ext/date/php_date.c:499: error: (near initialization for 
'ini_entries[0].mh_arg1')
make: *** [ext/date/php_date.lo] Error 1
iPod-Touch:~/php-5.3.3 root# 


Expected result:

to compile normal :)

Actual result:
--
fails to compile :(






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


[PHP-BUG] Bug #60884 [NEW]: htmlentities() behaves differently and thus breaks existing code

2012-01-25 Thread t dot nickl at exse dot de
From: 
Operating system: CentOS 4.4
PHP version:  5.4.0RC6
Package:  *General Issues
Bug Type: Bug
Bug description:htmlentities() behaves differently and thus breaks existing code

Description:

//This code must be run via web:

//This is a string from e.g. some database containing a german umlaut 'ä'.
Note the encoding really is iso8859-1 . It's just assigned here literally
to be concise.
$a = Rechnungsadresse ändern;

//this output works: (An empty string activates some autodetection)
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, ''));

//this works too (the same output is generated):
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1'));

//this does NOT work (outputs empty string)
var_dump(htmlentities($a));

// Reason: php changed the charset htmlentities uses when you NOT give
anything (90% of the code out there):

//determine_charset() :
///
// php-5.2.1/ext/standard/html.c :
///* Guarantee default behaviour for backwards compatibility */
//if (charset_hint == NULL)
//return cs_8859_1;
/
// php-5.4.0RC4/ext/standard/html.c :
//   /* Default is now UTF-8 */
//   if (charset_hint == NULL)
//return cs_utf_8;

// This breaks the meaning of existing german code. For example, typo3
outputs empty string if end users used german umlauts in rich text editor
in backend.

// Please change determine_charset() back to using cs_8859_1 if the third
parameter of htmlentities() is omitted.

Test script:
---
See description.

Expected result:

See description.

Actual result:
--
See description.

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



[PHP-BUG] Bug #60886 [NEW]: Random segmentation faults in autoload (PHP 5.3.9)

2012-01-25 Thread sefer at hotmail dot com
From: 
Operating system: Ubuntu Linux
PHP version:  5.3.9
Package:  *General Issues
Bug Type: Bug
Bug description:Random segmentation faults in autoload (PHP 5.3.9)

Description:

Hi,

I have been experiencing sporadic segmentation faults in our PHP 5.3.8/9 
(running as a module under Apache 2.2.21 in Ubuntu Linux ). We upgraded to
PHP 
5.3.9 but the random segmentation problems remain.
From the core dump I see that this is happening in our autoload function.

Here's how we register the autoload call:

spl_autoload_register(array(AutoLoadCache, autoload));


class AutoLoadCache
{
static public function autoload($class_name)
{
...
}
}

This is how we built our PHP instance:

./configure --prefix=/opt/php-5.3.9 --with-apxs2=/opt/httpd/bin/apxs
--enable-
zip --enable-zend-multibyte --enable-sysvshm --enable-sysvsem
--enable-sysvmsg -
-with-openssl --with-zlib --enable-calendar --with-zlib --enable-ftp
--enable-
intl --enable-intl --with-pgsql=/opt/postgresql --with-readline
--enable-sockets 
--enable-sqlite-utf8 --enable-soap --with-mcrypt=/opt/libmcrypt --enable-
mbstring --with-curl --with-gd --enable-gd-native-ttf --with-freetype-dir
--
with-gmp --with-gettext --with-jpeg-dir --with-png-dir


This is the stack trace:


Program terminated with signal 11, Segmentation fault.
#0  _zend_mm_alloc_int (heap=0x252ca10, size=112) at /home/rolley/t/php-
5.3.9/Zend/zend_alloc.c:1835
1835heap-cache[index] = best_fit-prev_free_block;
(gdb) bt
#0  _zend_mm_alloc_int (heap=0x252ca10, size=112) at /home/rolley/t/php-
5.3.9/Zend/zend_alloc.c:1835
#1  0x7f030e3e94ec in _zend_hash_add_or_update (ht=0x23b8e18,
arKey=value 
optimized out, nKeyLength=41, pData=0x7f03006d5fb8, 
nDataSize=value optimized out, pDest=0x7f03006d5fc0, flag=1) at 
/home/rolley/t/php-5.3.9/Zend/zend_hash.c:250
#2  0x7f030e45baf5 in zend_symtable_update (result=0x4451880,
container_ptr=
value optimized out, dim=0x23db538, 
dim_is_tmp_var=value optimized out, type=1, tsrm_ls=0x252a410) at 
/home/rolley/t/php-5.3.9/Zend/zend_hash.h:346
#3  zend_fetch_dimension_address_inner (result=0x4451880,
container_ptr=value 
optimized out, dim=0x23db538, 
dim_is_tmp_var=value optimized out, type=1, tsrm_ls=0x252a410) at 
/home/rolley/t/php-5.3.9/Zend/zend_execute.c:833
#4  zend_fetch_dimension_address (result=0x4451880, container_ptr=value 
optimized out, dim=0x23db538, 
dim_is_tmp_var=value optimized out, type=1, tsrm_ls=0x252a410) at 
/home/rolley/t/php-5.3.9/Zend/zend_execute.c:903
#5  0x7f030e465956 in ZEND_ASSIGN_DIM_SPEC_CV_CV_HANDLER 
(execute_data=0x44514a0, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/Zend/zend_vm_execute.h:29572
#6  0x7f030e404377 in execute (op_array=0x23d4ad8, tsrm_ls=0x252a410)
at 
/home/rolley/t/php-5.3.9/Zend/zend_vm_execute.h:107
#7  0x7f030e3cdf6f in zend_call_function (fci=0x7f03006d62c0,
fci_cache=
value optimized out, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/Zend/zend_execute_API.c:969
#8  0x7f030e3f4c61 in zend_call_method (object_pp=0x0, obj_ce=value 
optimized out, fn_proxy=0x23b9d68, 
function_name=0x23cb488 autoloadcache::autoload,
function_name_len=value 
optimized out, retval_ptr_ptr=0x7f03006d6408, 
param_count=1, arg1=0x23d4930, arg2=0x0, tsrm_ls=0x252a410) at 
/home/rolley/t/php-5.3.9/Zend/zend_interfaces.c:97
#9  0x7f030e28e07c in zif_spl_autoload_call (ht=value optimized out,

return_value=value optimized out, 
return_value_ptr=value optimized out, this_ptr=value optimized out,

return_value_used=value optimized out, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/ext/spl/php_spl.c:405
#10 0x7f030e3ce051 in zend_call_function (fci=0x7f03006d6610,
fci_cache=
value optimized out, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/Zend/zend_execute_API.c:991
#11 0x7f030e3ce9db in zend_lookup_class_ex (name=0x23ba1e8 
DatabaseFactory, name_length=15, use_autoload=1, ce=0x7f03006d6728, 
tsrm_ls=0x252a410) at
/home/rolley/t/php-5.3.9/Zend/zend_execute_API.c:1126
#12 0x7f030e3cf158 in zend_fetch_class (class_name=0x23ba1e8 
DatabaseFactory, class_name_len=15, fetch_type=0, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/Zend/zend_execute_API.c:1568
#13 0x7f030e42ed4b in
ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER 
(execute_data=0x4450c78, tsrm_ls=0x252a410)
at /home/rolley/t/php-5.3.9/Zend/zend_vm_execute.h:2689
#14 0x7f030e404377 in execute (op_array=0x23c3d88, tsrm_ls=0x252a410)
at 
/home/rolley/t/php-5.3.9/Zend/zend_vm_execute.h:107
#15 0x7f030e3dd2f5 in zend_execute_scripts (type=8, tsrm_ls=0x252a410,

retval=0x0, file_count=3)
at /home/rolley/t/php-5.3.9/Zend/zend.c:1236
---Type return to continue, or q return to quit---
#16 0x7f030e380273 in php_execute_script (primary_file=0x7f03006d8c40,

tsrm_ls=0x252a410) at /home/rolley/t/php-5.3.9/main/main.c:2308
#17 0x7f030e476fb2 in 

Bug #53227 [Com]: PHP Warning: mysql_pconnect(): MySQL server has gone away

2012-01-25 Thread david71rj at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=53227edit=1

 ID: 53227
 Comment by: david71rj at gmail dot com
 Reported by:tyra3l at gmail dot com
 Summary:PHP Warning:  mysql_pconnect(): MySQL server has
 gone away
 Status: Feedback
 Type:   Bug
 Package:MySQL related
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

No solution? I'm using PHP 5.3.8.


Previous Comments:

[2011-08-11 23:41:12] php at accounts dot brycedrennan dot com

I experience the same thing. 

PHP 5.3.2, Apache 2.2.17, Windows 7 64bit


[2010-12-25 13:50:57] ka...@php.net

Afair, we already have some checking code in the common connector function for 
ext/mysql to check for server has gone away when attempting to re-use a 
persistent connection. But it is hard to reproduce if the result isn't 
consistent.

I tried to reproduce it a few times, but without luck. Any specific MySQL 
Server versions, or other data that could provide useful?


[2010-12-20 14:34:06] tyra3l at gmail dot com

mysqlnd

Tyrael


[2010-12-20 14:22:52] and...@php.net

do you use libmysql or mysqlnd?


[2010-11-02 12:13:04] tyra3l at gmail dot com

Description:

On of my co-worker experienced, that some of the mysql_pconnect calls are 
returning this error.
The exact same symptoms are described in the manual:
http://php.net/manual/en/function.mysql-pconnect.php#99380
the code which produce this was working fine before migrating to 5.3

Test script:
---
?php
mysql_pconnect();

Expected result:

successful connection every time

Actual result:
--
sometimes we get the PHP warning, and we had to retry the connection






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


Bug #60876 [Com]: max_input_vars corrupt posted data

2012-01-25 Thread carloschilazo at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60876edit=1

 ID: 60876
 Comment by: carloschilazo at gmail dot com
 Reported by:jiri dot reischig at ecn dot cz
 Summary:max_input_vars corrupt posted data
 Status: Open
 Type:   Bug
 Package:*General Issues
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

I'm not sure as it would have to absolutley halt the execution; 

Some routines maybe in the script to handle those kind of situations, hence 
only a 
warning is issued


Previous Comments:

[2012-01-25 10:03:16] jiri dot reischig at ecn dot cz

Description:

When you post some data to the php script where are more variables than limit 
in max_input_vars the php script does not get any information that php don't 
put any of data to the system variables (for example $_REQUEST[]).
There is only PHP Warning generated but the php script is still running 
without any problem with corrupted dataset from post.

Solution will be to stop executing the script if max_input_vars is reached.

Without stoping the script you are working with currupted dataset and you can 
make some data inconsistencies in your aplication without any knowledge.

Test script:
---
max_input_vars = 1

sending post: test.php?a=1b=2c=3

print_r($_REQUEST);

Expected result:

Stop the script if max_input_vars is reached.


Actual result:
--
Array
(
[a] = 1
)






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


Bug #60756 [Com]: Unable to upgrade

2012-01-25 Thread carloschilazo at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60756edit=1

 ID: 60756
 Comment by: carloschilazo at gmail dot com
 Reported by:lucien_sabre at yahoo dot it
 Summary:Unable to upgrade
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows7 32Bit
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Try installing as an administrator (right click the installer, run as 
administrator) or disable windows UAC


Previous Comments:

[2012-01-18 07:53:41] lucien_sabre at yahoo dot it

So, what do I do?


[2012-01-17 19:59:46] anon at anon dot anon

It's not moronic to be a beginner, it's moronic to not just try it and learn by 
experimentation.


[2012-01-16 15:29:13] lucien_sabre at yahoo dot it

Once I back up the original files, what do I do? I'm a complete beginner 
***moron*** in these cases


[2012-01-16 14:53:38] anon at anon dot anon

So back up the install folder first then. But I doubt it can be too strangely 
laid out because I've never had a problem just running copies of PHP 
arbitrarily from extracted zips.


[2012-01-16 13:07:13] lucien_sabre at yahoo dot it

I tried downloading the zipped version, to simply overwrite the existing files, 
but I didn't understand where to put the files - and I'm a bit afraid of 
messing 
up current installation.




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=60756


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


Req #60844 [Opn-Bgs]: mysqlnd does not work with non-native pluggable authentication

2012-01-25 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60844edit=1

 ID: 60844
 Updated by: johan...@php.net
 Reported by:FM_Silver at gmx dot de
 Summary:mysqlnd does not work with non-native pluggable
 authentication
-Status: Open
+Status: Bogus
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Debian 6.0.3
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Pluggable authentication support was added to PHP 5.4. The auth_socket plugin 
works there:

mysql CREATE USER 'johannes'@'localhost' IDENTIFIED WITH auth_socket;
mysql exit
$ whoami
johannes
$ php54 -r '$mysqli = new mysqli(localhost, johannes, , test, 0, 
/tmp/mysql55.sock); echo $mysqli-query(show grants)-fetch_row()[0];'
GRANT USAGE ON *.* TO 'johannes'@'localhost'


Previous Comments:

[2012-01-23 01:00:16] FM_Silver at gmx dot de

Description:

Using mysql 5.5.19, loaded auth_socket plugin and created a user to auth with 
it:

mysql INSTALL PLUGIN auth_socket SONAME 'auth_socket.so';
mysql CREATE USER 'someuser'@'localhost' IDENTIFIED WITH auth_socket;

Also assume an existing database 'website'.

Trying to auth with user someuser works, when using the mysql client, but fails 
with mysqlnd as shown below.

Test script:
---
?php
$mysqli = new mysqli(localhost, someuser, , website);

if (mysqli_connect_errno()) {
printf(Connect failed: %s\n, mysqli_connect_error());
exit();
}

printf(Host information: %s\n, $mysqli-host_info);

$mysqli-close();
?

Expected result:

Host information: Localhost via UNIX socket

Actual result:
--
PHP Warning:  mysqli::mysqli(): (08004/1251): Client does not support 
authentication protocol requested by server; consider upgrading MySQL client in 
/home/someuser/mysql.php on line 2
PHP Stack trace:
PHP   1. {main}() /home/someuser/mysql.php:0
PHP   2. mysqli-mysqli() /home/someuser/mysql.php:2
Connect failed: Client does not support authentication protocol requested by 
server; consider upgrading MySQL client






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


Bug #60884 [Opn-Bgs]: htmlentities() behaves differently and thus breaks existing code

2012-01-25 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60884edit=1

 ID: 60884
 Updated by: johan...@php.net
 Reported by:t dot nickl at exse dot de
 Summary:htmlentities() behaves differently and thus breaks
 existing code
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 4.4
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

In PHP 5.4 the default_charset php.ini option was set to utf-8. You can 
override this in php.ini or .htaccess or such.


Previous Comments:

[2012-01-25 15:29:09] t dot nickl at exse dot de

Description:

//This code must be run via web:

//This is a string from e.g. some database containing a german umlaut 'ä'. 
Note the encoding really is iso8859-1 . It's just assigned here literally to be 
concise.
$a = Rechnungsadresse ändern;

//this output works: (An empty string activates some autodetection)
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, ''));

//this works too (the same output is generated):
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1'));

//this does NOT work (outputs empty string)
var_dump(htmlentities($a));

// Reason: php changed the charset htmlentities uses when you NOT give anything 
(90% of the code out there):

//determine_charset() :
///
// php-5.2.1/ext/standard/html.c :
///* Guarantee default behaviour for backwards compatibility */
//if (charset_hint == NULL)
//return cs_8859_1;
/
// php-5.4.0RC4/ext/standard/html.c :
//   /* Default is now UTF-8 */
//   if (charset_hint == NULL)
//return cs_utf_8;

// This breaks the meaning of existing german code. For example, typo3 outputs 
empty string if end users used german umlauts in rich text editor in backend.

// Please change determine_charset() back to using cs_8859_1 if the third 
parameter of htmlentities() is omitted.

Test script:
---
See description.

Expected result:

See description.

Actual result:
--
See description.






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


Bug #60883 [Opn-Fbk]: php_intl crach

2012-01-25 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=60883edit=1

 ID: 60883
 Updated by: cataphr...@php.net
 Reported by:bugzilla33 at gmail dot com
 Summary:php_intl crach
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   win 7
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.




Previous Comments:

[2012-01-25 14:58:50] bugzilla33 at gmail dot com

testscript.php

?php
 phpinfo();
?


[2012-01-25 14:52:41] bugzilla33 at gmail dot com

Description:

1. use Apache 2.2.21 VC9
2. download http://windows.php.net/downloads/qa/php-5.4.0RC6-Win32-VC9-x86.zip
3. unpack to c:\php5\
4. rename php.ini-development - php.ini
5. change php.ini:
   extension_dir = c:\php5\ext
   extension=php_intl.dll
6. restart apache
7. run any script


Test script:
---
any

Expected result:

no crash

Actual result:
--
crash






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


Bug #44383 [Opn]: PHP DateTime not converted to xsd:datetime

2012-01-25 Thread frozenfire
Edit report at https://bugs.php.net/bug.php?id=44383edit=1

 ID: 44383
 Updated by: frozenf...@php.net
 Reported by:kevin dot craft at gmail dot com
 Summary:PHP DateTime not converted to xsd:datetime
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   *
 PHP Version:5.*, 6 (2009-08-07
 Block user comment: N
 Private report: N

 New Comment:

I've encountered this issue today, and it would be really wonderful to have 
this 
patch applied.


Previous Comments:

[2010-10-18 17:43:04] aldekein at myevil dot info

It still does not work after 2.5 years in PHP 5.3.1 on Windows.

Maybe this patch should be applied to official PHP branch?


[2009-08-07 15:23:57] david dot zuelke at bitextender dot com

Updated patch and tests: http://pastie.org/575559


[2009-06-29 08:56:29] lsm...@php.net

Reopening since we now have a patch.


[2009-06-29 08:28:26] david dot zuelke at bitextender dot com

We've created a patch to implement this.

Description (with patch and tests for download):
http://article.gmane.org/gmane.comp.php.devel/57369

Patch (in case gmane doesn't work):
http://pastie.org/527755

Tests (in case gmane doesn't work):
http://pastie.org/527762


[2008-06-30 12:00:56] r dot janssen at keensystems dot eu

I am, too, looking for a solution for this problem.
I can specify parameters as dateTime type but when generating the WSDL the 
generation stops and does nothing.




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=44383


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


[PHP-BUG] Bug #60887 [NEW]: SoapClient ignores user_agent option and sends no User-Agent header

2012-01-25 Thread mail at tomsommer dot dk
From: 
Operating system: 
PHP version:  5.3.9
Package:  SOAP related
Bug Type: Bug
Bug description:SoapClient ignores user_agent option and sends no User-Agent 
header

Description:

The SoapClient ignores the user_agent option, and sends no User-Agent at
all.

Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' =
'foo'));


Expected result:

User-Agent header on the remote server

Actual result:
--
No User-Agent header on the remote server

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



Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header

2012-01-25 Thread mail at tomsommer dot dk
Edit report at https://bugs.php.net/bug.php?id=60887edit=1

 ID: 60887
 Comment by: mail at tomsommer dot dk
 Reported by:mail at tomsommer dot dk
 Summary:SoapClient ignores user_agent option and sends no
 User-Agent header
 Status: Open
 Type:   Bug
 Package:SOAP related
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

The receiving server only receive the following headers:

GET / HTTP/1.1
Host: www.example.com
Connection: close

Checked with tcpdump


Previous Comments:

[2012-01-25 20:45:55] mail at tomsommer dot dk

Description:

The SoapClient ignores the user_agent option, and sends no User-Agent at all.

Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' = 
'foo'));


Expected result:

User-Agent header on the remote server

Actual result:
--
No User-Agent header on the remote server






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


Bug #60884 [Bgs]: htmlentities() behaves differently and thus breaks existing code

2012-01-25 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=60884edit=1

 ID: 60884
 Updated by: ras...@php.net
 Reported by:t dot nickl at exse dot de
 Summary:htmlentities() behaves differently and thus breaks
 existing code
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 4.4
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

I know it hurts, but we really need to move away from ISO-8859-1 and towards 
UTF-8 as the default charset of the Web. We have chosen to take the hit in 5.4. 
The documentation has carried a warning about this impending change for quite a 
while urging people to specify a charset.

For PHP 5.4 compatibility Typo3 should either hardcode iso-8859-1 or they 
should 
change their calls to:

  htmlentities($a,NULL,'')

to pick up the default script-encoding charset.


Previous Comments:

[2012-01-25 18:01:23] johan...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

In PHP 5.4 the default_charset php.ini option was set to utf-8. You can 
override this in php.ini or .htaccess or such.


[2012-01-25 15:29:09] t dot nickl at exse dot de

Description:

//This code must be run via web:

//This is a string from e.g. some database containing a german umlaut 'ä'. 
Note the encoding really is iso8859-1 . It's just assigned here literally to be 
concise.
$a = Rechnungsadresse ändern;

//this output works: (An empty string activates some autodetection)
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, ''));

//this works too (the same output is generated):
var_dump(htmlentities($a, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1'));

//this does NOT work (outputs empty string)
var_dump(htmlentities($a));

// Reason: php changed the charset htmlentities uses when you NOT give anything 
(90% of the code out there):

//determine_charset() :
///
// php-5.2.1/ext/standard/html.c :
///* Guarantee default behaviour for backwards compatibility */
//if (charset_hint == NULL)
//return cs_8859_1;
/
// php-5.4.0RC4/ext/standard/html.c :
//   /* Default is now UTF-8 */
//   if (charset_hint == NULL)
//return cs_utf_8;

// This breaks the meaning of existing german code. For example, typo3 outputs 
empty string if end users used german umlauts in rich text editor in backend.

// Please change determine_charset() back to using cs_8859_1 if the third 
parameter of htmlentities() is omitted.

Test script:
---
See description.

Expected result:

See description.

Actual result:
--
See description.






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


[PHP-BUG] Req #60889 [NEW]: make array keys changeable

2012-01-25 Thread marc-bennewitz at arcor dot de
From: 
Operating system: 
PHP version:  Irrelevant
Package:  Arrays related
Bug Type: Feature/Change Request
Bug description:make array keys changeable

Description:

On working with maps it's often needed to change the key of an existing
element of an array, but it's currently not possible without a copy of the
array or a unset + new element.

Test script:
---
// function to change the key
$arr = array('a' = 'a');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (warning existing key)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (overwrite existing element)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b', true);
var_dump($arr);


echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (leave existing element)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b', false);
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// foreach key as ref
$arr = array('a' = 'a', 'b' = 'b');
foreach ($arr as $k = $v) {
$k = 'b';
}


Expected result:

array(1) {
  [b]=
  string(1) a
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  [a]=
  string(1) a,
  [b]=
  string(1) b
}
###
array(1) {
  [b]=
  string(1) a
}
###
array(1) {
  [b]=
  string(1) b
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  [a]=
  string(1) a,
  [b]=
  string(1) b
}

Actual result:
--
Function related:
There is no funcation to change an array key

foreach related:
PHP Fatal error:  Key element cannot be a reference

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



Req #60889 [Opn-Wfx]: make array keys changeable

2012-01-25 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=60889edit=1

 ID: 60889
 Updated by: johan...@php.net
 Reported by:marc-bennewitz at arcor dot de
 Summary:make array keys changeable
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Your requested function can be written like this:

function array_change_key($arr, $old, $new) {
if (isset($arr[$new]) {
trigger_error(...);
}
$arr[$new] = $arr[$old];
unset($arr[$old]);
}

This creates neither a copy of the array nor of the element ... due to copy on 
rite. And it's exactly hat we would do internally.

PHP already has many array funtions and we won't add new ones which can be 
implemented easily in userland.


Previous Comments:

[2012-01-26 00:06:08] marc-bennewitz at arcor dot de

Description:

On working with maps it's often needed to change the key of an existing element 
of an array, but it's currently not possible without a copy of the array or a 
unset + new element.

Test script:
---
// function to change the key
$arr = array('a' = 'a');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (warning existing key)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b');
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (overwrite existing element)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b', true);
var_dump($arr);


echo PHP_EOL . '###' . PHP_EOL;

// function to change the key (leave existing element)
$arr = array('a' = 'a', 'b' = 'b');
array_change_key($arr, 'a', 'b', false);
var_dump($arr);

echo PHP_EOL . '###' . PHP_EOL;

// foreach key as ref
$arr = array('a' = 'a', 'b' = 'b');
foreach ($arr as $k = $v) {
$k = 'b';
}


Expected result:

array(1) {
  [b]=
  string(1) a
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  [a]=
  string(1) a,
  [b]=
  string(1) b
}
###
array(1) {
  [b]=
  string(1) a
}
###
array(1) {
  [b]=
  string(1) b
}
###
Warning: Can't change the array key 'a' to an already existing key 'b'
array(2) {
  [a]=
  string(1) a,
  [b]=
  string(1) b
}

Actual result:
--
Function related:
There is no funcation to change an array key

foreach related:
PHP Fatal error:  Key element cannot be a reference






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


Bug #60837 [Opn-Csd]: Segmentation fail, if use trait

2012-01-25 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60837edit=1

 ID: 60837
 Updated by: larue...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-01-24 06:46:57] piphon at gmail dot com

I check svn head, when https://bugs.php.net/bug.php?id=60840 fixed


[2012-01-24 06:27:54] piphon at gmail dot com

Snapshot PHP 5.4.0RC7-dev (cli) (built: Jan 24 2012 11:49:24) worked.

Sorry, can't try SVN branch 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4@322646). Could not 
compile sources for test issue. Modules (pdo, pdo_mysql) not compiled as static 
libraries (multiple definition of `get_module') or pdo_mysql not linked as 
shared library (mysqlnd_debug_std_no_trace_funcs not found). And debugging and 
normal. I'll try again.


[2012-01-24 05:32:44] larue...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

could you plz also try with 5.4 branch head? thanks very much :)


[2012-01-24 04:27:25] piphon at gmail dot com

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.


[2012-01-24 03:00:37] larue...@php.net

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revisionrevision=322495




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=60837


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


Bug #60825 [Ctl-Csd]: Segfault when running symfony 2 tests

2012-01-25 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60825edit=1

 ID: 60825
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault when running symfony 2 tests
-Status: Critical
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.04.3 LTS
 PHP Version:5.4.0RC6
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-01-26 01:21:34] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=322770
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-01-24 14:39:45] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=322678
Log: Re-fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-01-24 02:50:37] larue...@php.net

assign to myself, will close after commit to 5.4 branch


[2012-01-21 17:29:04] larue...@php.net

fixed in trunk, will commit to branch when I got the permission from stas, and 
a   
simple reproduce script:

?php
class test {
public function __toString() {
return aaa;
}
}

$a = new test;

require_once $a;


[2012-01-21 17:13:54] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=322541
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)




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=60825


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


Bug #60837 [Csd-ReO]: Segmentation fail, if use trait

2012-01-25 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60837edit=1

 ID: 60837
 Updated by: larue...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

oh, I mis-read  your words, re-opened.


Previous Comments:

[2012-01-26 01:15:32] larue...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




[2012-01-24 06:46:57] piphon at gmail dot com

I check svn head, when https://bugs.php.net/bug.php?id=60840 fixed


[2012-01-24 06:27:54] piphon at gmail dot com

Snapshot PHP 5.4.0RC7-dev (cli) (built: Jan 24 2012 11:49:24) worked.

Sorry, can't try SVN branch 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4@322646). Could not 
compile sources for test issue. Modules (pdo, pdo_mysql) not compiled as static 
libraries (multiple definition of `get_module') or pdo_mysql not linked as 
shared library (mysqlnd_debug_std_no_trace_funcs not found). And debugging and 
normal. I'll try again.


[2012-01-24 05:32:44] larue...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

could you plz also try with 5.4 branch head? thanks very much :)


[2012-01-24 04:27:25] piphon at gmail dot com

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.




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=60837


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


Bug #60765 [Com]: mysqli_real_escape_string not parse multibyte word safe while use mysqlnd

2012-01-25 Thread xiaqii at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60765edit=1

 ID: 60765
 Comment by: xiaqii at gmail dot com
 Reported by:xiaqii at gmail dot com
 Summary:mysqli_real_escape_string not parse multibyte word
 safe while use mysqlnd
 Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   ubuntu 10
 PHP Version:5.3.9
 Assigned To:uw
 Block user comment: N
 Private report: N

 New Comment:

my site's charset is GBK


Previous Comments:

[2012-01-16 06:19:58] xiaqii at gmail dot com

i recomplie my php with old style 
--with-mysqli=/usr/local/mysql/bin/mysql_config' 

the sql is safe and execute ok.

so the bug is : mysqlnd not parse some multibyte word.
this can be sql injection problem.

i hope my english is enough to explain this bug clearly..  -_-!


[2012-01-16 05:50:24] xiaqii at gmail dot com

Description:

some Multibyte word contain \ ASCII code didn't been escaped.

Test script:
---
$link=mysqli_connect();
$var=海賊;
$var=mysqli_real_escape_string($link,$var);
mysqli_query($link,INSERT INTO table SET manga_name='$var');
///


Expected result:

sql injection

Actual result:
--
it is dangerous.
my reply table has been update to all one word because this..






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


Req #60872 [Com]: server-side comment tag

2012-01-25 Thread carloschilazo at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60872edit=1

 ID: 60872
 Comment by: carloschilazo at gmail dot com
 Reported by:mantoxpub at people dot it
 Summary:server-side comment tag
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Why not use

/*
comment
*/

or // comment

?


Previous Comments:

[2012-01-24 19:16:02] mantoxpub at people dot it

Description:

---
From manual page: http://www.php.net/language.basic-syntax.comments
---

what about supporting server-side comment tag?



Test script:
---
%-- this is a server-side comment. --%

Expected result:

(nothing :)

Actual result:
--
%-- this is a server-side comment. --%






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


Bug #60887 [Com]: SoapClient ignores user_agent option and sends no User-Agent header

2012-01-25 Thread mail at tomsommer dot dk
Edit report at https://bugs.php.net/bug.php?id=60887edit=1

 ID: 60887
 Comment by: mail at tomsommer dot dk
 Reported by:mail at tomsommer dot dk
 Summary:SoapClient ignores user_agent option and sends no
 User-Agent header
 Status: Open
 Type:   Bug
 Package:SOAP related
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Workaround is:

$opts = array(
  'http'=array(
'user_agent' = 'foo'
  )
);

$context = stream_context_create($opts);
$client = new SoapClient('http://www.example.com/', array('stream_context' = 
$context));


Previous Comments:

[2012-01-25 20:55:06] mail at tomsommer dot dk

The receiving server only receive the following headers:

GET / HTTP/1.1
Host: www.example.com
Connection: close

Checked with tcpdump


[2012-01-25 20:45:55] mail at tomsommer dot dk

Description:

The SoapClient ignores the user_agent option, and sends no User-Agent at all.

Test script:
---
$client = new SoapClient('http://www.example.com/', array('user_agent' = 
'foo'));


Expected result:

User-Agent header on the remote server

Actual result:
--
No User-Agent header on the remote server






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