Bug #64195 [Com]: clone object with circular reference cause segfault

2013-02-12 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=64195&edit=1

 ID: 64195
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:clone object with circular reference cause segfault
 Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   linux
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Ok. Why I cannot get same error for simple function recursion with memory_limit 
= -1?

$ php -d memory_limit=-1 -r 'function f() { f(); } f();'

I has x64 with 8 GB RAM. For thise short test I see large memory usage (with 
some system freezes), but there are no stack overflow. The subject test code 
goes to segfault too quickly, I think. Are you really sure there are no errors 
here?


Previous Comments:

[2013-02-12 11:49:35] 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

Infinite recursion leads to a stack overflow (clone calls clone, calls clone, 
calls clone, ...) we have no good way to handle this.


[2013-02-12 11:33:20] vovan-ve at yandex dot ru

Description:

There are two objects of the same class. Both objects has a property. There are
circular object reference: $a->prop === $b && $b->prop === $a. The class has
a __clone() handler which clones object in that property.

So, clonning such object cause segfault.

Yes, described architecture is ugly, but this is just for test.

Test code:


class A {
public $prop;

public function __clone() {
$this->prop = clone $this->prop;
}
}

// create two objects
$a = new A();
$b = new A();

// create circular reference
$b->prop = $a;
$a->prop = $b;

// see short dump with *RECURSION* marker
print_r($a);

// now make a problem
$c = clone $a;

// never will reach here
print_r($c);


5.5.0.a2, 5.4.11, 5.3.20 and 5.2.17 crashes with segfault. It is infinite
recursion. Also Fatal Error can be emited about memory allocation when small
memory_limit is set (1M for example).

Unlimited recursion for a simple function cause a fatal error, so the bug 
always should cause the same fatal error.

Test script:
---
class A {
public $prop;

public function __clone() {
$this->prop = clone $this->prop;
}
}

$a = new A();
$b = new A();

$b->prop = $a;
$a->prop = $b;

print_r($a);

$c = clone $a;
print_r($c);

Expected result:

A Object
(
[prop] => A Object
(
[prop] => A Object
 *RECURSION*
)

)

Fatal error: Allowed memory size of ... bytes exhausted (tried to allocate ... 
bytes)

Actual result:
--
A Object
(
[prop] => A Object
(
[prop] => A Object
 *RECURSION*
)

)
Segmentation fault (core dumped)






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

[PHP-BUG] Bug #64195 [NEW]: clone object with circular reference cause segfault

2013-02-12 Thread vovan-ve at yandex dot ru 
From: vovan-ve at yandex dot ru
Operating system: linux
PHP version:  5.4.11
Package:  Class/Object related
Bug Type: Bug
Bug description:clone object with circular reference cause segfault

Description:

There are two objects of the same class. Both objects has a property. There
are
circular object reference: $a->prop === $b && $b->prop === $a. The class
has
a __clone() handler which clones object in that property.

So, clonning such object cause segfault.

Yes, described architecture is ugly, but this is just for test.

Test code:


class A {
public $prop;

public function __clone() {
$this->prop = clone $this->prop;
}
}

// create two objects
$a = new A();
$b = new A();

// create circular reference
$b->prop = $a;
$a->prop = $b;

// see short dump with *RECURSION* marker
print_r($a);

// now make a problem
$c = clone $a;

// never will reach here
print_r($c);


5.5.0.a2, 5.4.11, 5.3.20 and 5.2.17 crashes with segfault. It is infinite
recursion. Also Fatal Error can be emited about memory allocation when
small
memory_limit is set (1M for example).

Unlimited recursion for a simple function cause a fatal error, so the bug
always should cause the same fatal error.

Test script:
---
class A {
public $prop;

public function __clone() {
$this->prop = clone $this->prop;
}
}

$a = new A();
$b = new A();

$b->prop = $a;
$a->prop = $b;

print_r($a);

$c = clone $a;
print_r($c);

Expected result:

A Object
(
[prop] => A Object
(
[prop] => A Object
 *RECURSION*
)

)

Fatal error: Allowed memory size of ... bytes exhausted (tried to allocate
... bytes)

Actual result:
--
A Object
(
[prop] => A Object
(
[prop] => A Object
 *RECURSION*
)

)
Segmentation fault (core dumped)

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

[PHP-BUG] Bug #63659 [NEW]: Type hint 'self' means plain 'self' instead of original target class

2012-11-30 Thread vovan-ve at yandex dot ru 
From: vovan-ve at yandex dot ru
Operating system: 
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Bug
Bug description:Type hint 'self' means plain 'self' instead of original target 
class

Description:

It seems to me, there is some unclear situation with keywords «self»
(and «parent»). At least this keywords has no detailed documentation.

Imaging following interface:

interface IFoo {
public function lorem(IFoo $foo);
public function ipsum(self $foo);
}

The first method lorem() wants an implementation of IFoo as argument. The
one
problem here is a duplication of the name IFoo inside itself. Usage of
keyword
«self» should prevent this "problem", but in theory only.

The second method ipsum() extects an instance of... of what? In fact, it
wants
an instance of «self» - that is an instance of implementation class,
which
implements or even overrides the method later.

The problem is the fact, that keyword «self» means SELF, not a class or
an interface, there it is writen. We cannot change «self» to «IFoo» in
implementation:

interface IFoo {
public function ipsum(self $foo);
}

class Fail implements IFoo {
public function ipsum(IFoo $foo) {
}
}
// Error: Fail::ipsum() must be compatible with IFoo::ipsum()

The ReflectionClass shows «IFoo», «self» and «parent» for
corresponding methods:

interface IFoo {
public function lorem(IFoo $foo);
public function ipsum(self $foo);
public function dolor(parent $foo);
}

$ref = new ReflectionClass('IFoo');
echo $ref;

Output:

Method [  abstract public method lorem ] {
  - Parameters [1] {
Parameter #0 [  IFoo $foo ]
  }
}
Method [  abstract public method ipsum ] {
  - Parameters [1] {
Parameter #0 [  self $foo ]
  }
}
Method [  abstract public method dolor ] {
  - Parameters [1] {
Parameter #0 [  parent $foo ]
  }
}

When we write «self» somewhere, we mean that thing, where «self» is
writen.
I think, that method ipsum() should be compiled to receive instance of
IFoo
and nothing else. The method dolor() shoult to emit fatal error, because
IFoo
has no parent.

If I mistake with that deep meaning if the keywords «self» and
«parent»,
and this isn't a bug, I sure this keywords should be documented properly.

Test script:
---
interface IFoo {
public function ipsum(self $foo);
}

class Bar implements IFoo {
public function ipsum(self $foo) {
echo __METHOD__, "(", get_class($foo), ")\n";
}
}

class Baz extends Bar {
public function ipsum(self $foo) {
echo __METHOD__, "(", get_class($foo), ")\n";
}
}

class Lol implements IFoo {
public function ipsum(self $foo) {
echo __METHOD__, "(", get_class($foo), ")\n";
}
}

# test objects
$bar = new Bar();
$baz = new Baz();
$lol = new Lol();

# lets try everything

# IFoo::ipsum(self $foo)

# Bar::ipsum(self $foo)
$bar->ipsum($bar); # Bar::ipsum(Bar)
$bar->ipsum($baz); # Bar::ipsum(Baz)
$bar->ipsum($lol); # Error: Bar::ipsum() extects Bar, but Lol given

# Baz::ipsum(self $foo)
$baz->ipsum($bar); # Error: Baz::ipsum() extects Baz, but Bar given
$baz->ipsum($baz); # Baz::ipsum(Baz)
$baz->ipsum($lol); # Error: Baz::ipsum() extects Baz, but Lol given

# Lol::ipsum(self $foo)
$lol->ipsum($bar); # Error: Lol::ipsum() extects Lol, but Bar given
$lol->ipsum($baz); # Error: Lol::ipsum() extects Lol, but Baz given
$lol->ipsum($lol); # Lol::ipsum(Lol)

Expected result:

Bar::ipsum(Bar)
Bar::ipsum(Baz)
Bar::ipsum(Lol)
Baz::ipsum(Bar)
Baz::ipsum(Baz)
Baz::ipsum(Lol)
Lol::ipsum(Bar)
Lol::ipsum(Baz)
Lol::ipsum(Lol)

Actual result:
--
Bar::ipsum(Bar)
Bar::ipsum(Baz)
Catchable fatal error:  Argument 1 passed to Bar::ipsum() must be an
instance of Bar, instance of Lol given, called in ... and defined ...


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63659&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63659&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63659&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63659&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63659&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63659&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63659&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63659&r=needscript
Try newer version:  https://bugs.php.net/f

[PHP-BUG] Bug #63111 [NEW]: is_callable() lies for abstract static method

2012-09-18 Thread vovan-ve at yandex dot ru 
From: vovan-ve at yandex dot ru
Operating system: 
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Bug
Bug description:is_callable() lies for abstract static method

Description:

The function is_callable() says, that abstract static method _IS_ callable.
But it is abstract, it has no body.

abstract class Foo {
abstract static function bar();
}
# PHP Strict Standards: Static function Foo::bar() should not be
abstract
# is Foo::bar() callable?
var_dump( is_callable(array("Foo", "bar")) );
# bool(true)
# O_o Ok, let's try...
Foo::bar();
# Fatal error: Cannot call abstract method Foo::bar()

Yes, I see a Strict. Anyway, is_callable() lies. I have checked this in
5.3.10, 5.3.6 and 5.2.17.

Test script:
---
abstract class Foo {
abstract static function bar();
}

var_dump( is_callable(array("Foo", "bar")) );
Foo::bar();


Expected result:

bool(false)
Fatal error

Actual result:
--
bool(true)
Fatal error

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

Req #55633 [Com]: New argument $invert for array_filter()

2012-08-20 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55633&edit=1

 ID: 55633
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:New argument $invert for array_filter()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Related RFC was created: "array_delete() for elements deletion" - 
https://wiki.php.net/rfc/array_delete


Previous Comments:

[2012-01-23 23:44:37] vovan-ve at yandex dot ru

> Use Closures

Usage of any user-defined function as a callback anywhere will reduce 
performance. I think, it is much better to improve array_filter() as mentioned 
above.


[2012-01-23 22:39:24] gmblar+php at gmail dot com

Use Closures

$values = array(42, 'foo', false, null, array(), '');
var_dump(array_filter($values, function($value) {
return !is_null($value);
}));

------------
[2011-09-07 11:58:51] vovan-ve at yandex dot ru

Description:

I think, it would be useful to add new argument $invert to array_filter() 
function. It will be most useful to use built-in functions as a callback. For 
example this call:

$result = array_filter($values, 'is_null', true);

should to _remove_ all NULLs from array.

May be the parameter should be named $positive and have default value TRUE (and 
FALSE for inversion) to make code readable.

Test script:
---
$values = array(42, 'foo', false, null, array(), '');
var_dump(
  array_filter($values, null, true), // no callback - leave false value
  array_filter($values, 'is_null', true) // leave non-null values
);

Expected result:

array(5) {
  [0]=>
  bool(false)
  [1]=>
  NULL
  [2]=>
  array(0) {
  }
  [3]=>
  string(0) ""
}
array(5) {
  [0]=>
  int(42)
  [1]=>
  string(3) "foo"
  [2]=>
  bool(false)
  [3]=>
  array(0) {
  }
  [4]=>
  string(0) ""
}







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

Bug #55061 [Com]: Array autoindex[] overflow

2012-02-27 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55061&edit=1

 ID: 55061
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Array autoindex[] overflow
 Status: Open
 Type:   Bug
 Package:Arrays related
 Operating System:   WindowsXP SP3
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Reproduced with the same behaviour and result in Ubuntu 11.10 i386.


Previous Comments:

[2011-07-29 14:39:20] vovan-ve at yandex dot ru

No, I have no non-official extensions. I have disabled all extensions for test 
even. May be your int is not int32?


[2011-07-27 06:52:24] larue...@php.net

I can not reproduce this warning, do you have non-php-official extension 
installed?

if yes, plz remove them then check again. thanks


[2011-06-29 06:03:07] vovan-ve at yandex dot ru

Sorry for typo. var_dymp == var_dump


[2011-06-29 04:47:05] vovan-ve at yandex dot ru

Description:

There is a test code:

  $a = array(0x7FFF => 42);
  $a[] = 37;
  var_dymp($a);

Second line emits warning:

  Warning: Cannot add element to the array as the next element
  is already occupied in ... on line 2

and doesn't add element with value 37. This is absolutely abnormal
behaviour. At least there is incorrect text for Warning. I expect,
the element should be added with any index (i.e. string "2147483648"
as the result of 0x7FFF+1 thru float), or something else. But
element was not added even.

Test script:
---
$a = array(0x7FFF => 42);
$a[] = 37;
var_dymp($a);

Expected result:

array(1) {
  [2147483647]=>
  int(42)
  ["2147483648"]=>
  int(37)
}

OR (when int will become int64):

array(1) {
  [2147483647]=>
  int(42)
  [2147483648]=>
  int(37)
}

Actual result:
--
Warning: Cannot add element to the array as the next element is already 
occupied in ... on line 2
array(1) {
  [2147483647]=>
  int(42)
}






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

Req #55633 [Com]: New argument $invert for array_filter()

2012-01-23 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55633&edit=1

 ID: 55633
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:New argument $invert for array_filter()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

> Use Closures

Usage of any user-defined function as a callback anywhere will reduce 
performance. I think, it is much better to improve array_filter() as mentioned 
above.


Previous Comments:

[2012-01-23 22:39:24] gmblar+php at gmail dot com

Use Closures

$values = array(42, 'foo', false, null, array(), '');
var_dump(array_filter($values, function($value) {
return !is_null($value);
}));


[2011-09-07 11:58:51] vovan-ve at yandex dot ru

Description:

I think, it would be useful to add new argument $invert to array_filter() 
function. It will be most useful to use built-in functions as a callback. For 
example this call:

$result = array_filter($values, 'is_null', true);

should to _remove_ all NULLs from array.

May be the parameter should be named $positive and have default value TRUE (and 
FALSE for inversion) to make code readable.

Test script:
---
$values = array(42, 'foo', false, null, array(), '');
var_dump(
  array_filter($values, null, true), // no callback - leave false value
  array_filter($values, 'is_null', true) // leave non-null values
);

Expected result:

array(5) {
  [0]=>
  bool(false)
  [1]=>
  NULL
  [2]=>
  array(0) {
  }
  [3]=>
  string(0) ""
}
array(5) {
  [0]=>
  int(42)
  [1]=>
  string(3) "foo"
  [2]=>
  bool(false)
  [3]=>
  array(0) {
  }
  [4]=>
  string(0) ""
}







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

Bug #26678 [Com]: preg_quote doesn't quote forward slashes

2012-01-12 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=26678&edit=1

 ID: 26678
 Comment by: vovan-ve at yandex dot ru
 Reported by:gnif at spacevs dot com
 Summary:preg_quote doesn't quote forward slashes
 Status: Bogus
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Debain
 PHP Version:4.3.2
 Block user comment: N
 Private report: N

 New Comment:

I'm sorry for necroposting.

Why optional value for $delimiter is NULL? I cannot understand, when I must not 
escape any delimiter? PCRE always requires delimiter for regexp. I think, there 
are no such situation, when delimiter can be omitted.

OTOH, preg_quote() must not suppose, that delimiter is slash by default due to 
there are no defaults to delimiter in regexp. In this case, why $delimiter _is_ 
optional?


Previous Comments:

[2003-12-20 02:50:19] e...@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

see http://www.php.net/preg_quote 

echo preg_quote($file, \"/\");



[2003-12-19 21:58:20] gnif at spacevs dot com

Description:

if you use preg_quote to escape a string with forward slashes in it, it doesn't 
quote them.

Reproduce code:
---
$file = 'pages/box/test.php';
echo preg_quote($file);

Expected result:

pages\/box\/test\.php

Actual result:
--
pages/box/test\.php






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

[PHP-BUG] Req #55633 [NEW]: New argument $invert for array_filter()

2011-09-07 Thread vovan-ve at yandex dot ru 
From: 
Operating system: 
PHP version:  Irrelevant
Package:  Arrays related
Bug Type: Feature/Change Request
Bug description:New argument $invert for array_filter()

Description:

I think, it would be useful to add new argument $invert to array_filter()
function. It will be most useful to use built-in functions as a callback.
For example this call:

$result = array_filter($values, 'is_null', true);

should to _remove_ all NULLs from array.

May be the parameter should be named $positive and have default value TRUE
(and FALSE for inversion) to make code readable.

Test script:
---
$values = array(42, 'foo', false, null, array(), '');
var_dump(
  array_filter($values, null, true), // no callback - leave false value
  array_filter($values, 'is_null', true) // leave non-null values
);

Expected result:

array(5) {
  [0]=>
  bool(false)
  [1]=>
  NULL
  [2]=>
  array(0) {
  }
  [3]=>
  string(0) ""
}
array(5) {
  [0]=>
  int(42)
  [1]=>
  string(3) "foo"
  [2]=>
  bool(false)
  [3]=>
  array(0) {
  }
  [4]=>
  string(0) ""
}


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

Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope

2011-08-24 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1

 ID: 55493
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Superglobal variable variables with ${expression} in
 non-global scope
 Status: Assigned
 Type:   Feature/Change Request
 Package:Variables related
 Operating System:   Windows XP SP3
 PHP Version:5.3.7
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Programmers, who use variable variable, dooms themself to slowdown performance 
at any way due to calculation of the expressions. They won't see the 
difference, I think.


Previous Comments:

[2011-08-24 14:00:39] vovan-ve at yandex dot ru

But what about SUPERglobal? In fact they are almost superglobal :)


[2011-08-24 13:54:34] larue...@php.net

+1 for dmitry


[2011-08-24 13:04:22] dmi...@php.net

ZE decides if a variable have to be fetched from the global scope at compile 
time checking predefined list of super-global variables.

The variable fetching by name (e.g. $$name) is always done from local scope.

Of course it's possible to extend executor to check for list of super-global 
variables at run-time, but it'll introduce significant slowdown for each fetch 
by name. I really don't like it.


[2011-08-24 12:50:02] larue...@php.net

In this case, I make a patch for this, and the test result can be found on: 
http://pastebin.com/6pTuLEer


[2011-08-24 12:48:57] larue...@php.net

The following patch has been added/updated:

Patch Name: bug55493.patch
Revision:   1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137




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


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

Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope

2011-08-24 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1

 ID: 55493
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Superglobal variable variables with ${expression} in
 non-global scope
 Status: Assigned
 Type:   Feature/Change Request
 Package:Variables related
 Operating System:   Windows XP SP3
 PHP Version:5.3.7
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

But what about SUPERglobal? In fact they are almost superglobal :)


Previous Comments:

[2011-08-24 13:54:34] larue...@php.net

+1 for dmitry


[2011-08-24 13:04:22] dmi...@php.net

ZE decides if a variable have to be fetched from the global scope at compile 
time checking predefined list of super-global variables.

The variable fetching by name (e.g. $$name) is always done from local scope.

Of course it's possible to extend executor to check for list of super-global 
variables at run-time, but it'll introduce significant slowdown for each fetch 
by name. I really don't like it.


[2011-08-24 12:50:02] larue...@php.net

In this case, I make a patch for this, and the test result can be found on: 
http://pastebin.com/6pTuLEer


[2011-08-24 12:48:57] larue...@php.net

The following patch has been added/updated:

Patch Name: bug55493.patch
Revision:   1314190137
URL:
https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137


[2011-08-24 10:21:23] vovan-ve at yandex dot ru

When I tried to obfuscate a part of code I was surprised by this strange 
behariour. Of course, current implementation is correct on the one hand. But on 
the other hand the situation looks funny: this way is allowad, and this too, 
but this is not.




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


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

Req #55493 [Com]: Superglobal variable variables with ${expression} in non-global scope

2011-08-24 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55493&edit=1

 ID: 55493
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Superglobal variable variables with ${expression} in
 non-global scope
 Status: Assigned
 Type:   Feature/Change Request
 Package:Variables related
 Operating System:   Windows XP SP3
 PHP Version:5.3.7
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

When I tried to obfuscate a part of code I was surprised by this strange 
behariour. Of course, current implementation is correct on the one hand. But on 
the other hand the situation looks funny: this way is allowad, and this too, 
but this is not.


Previous Comments:

[2011-08-24 04:11:14] larue...@php.net

sure, it can be fixed by decide target symbol table again in the execution time 
for not const OPs, 

but I don't think this is really necessary . :)


[2011-08-23 18:16:12] ka...@php.net

This still seems a little strange that we cannot pick the correct symbol table 
at compile time, all it should need would be a check to see if the compiled 
value is matching one thats a super global.

I remember to have encountered something similar a while back, which I'm not 
sure if I reported or not, but def. something we should look into at some point.

Dmitry, can you clarify this?


[2011-08-23 16:49:00] larue...@php.net

As I said, this is a limitation of PHP design, so mark as won't fix. 
Thank you for your interest in PHP.


[2011-08-23 16:22:46] larue...@php.net

when fetching a variable, the target symbol table is decided in compiling time, 
 
for the script above,  in compiling time, only const string "_SERVER" can be 
took consider as a SUPERVAR and assign the global symbol table as 
target_symbol_table.

the others `varname` only can be see in execution time, so Zend VM think it 
should be fetched from a local symbol table.

and the 'local symbol table' for the global scope statement is actual 'global 
symbol table', therefor it works 'as expected'.

--------------------
[2011-08-23 14:14:42] vovan-ve at yandex dot ru

Description:

ONLY Superglobal variable variables does not work ONLY in non-global
scope and ONLY with non-constant expression. See test script.

I found Req 38527, but it does not describe the problem properly and
due to misunderstanding it has status Feature Request instead of Bug
(and also it is too old).

Test script:
---
// in global scope everything is right
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
echo PHP_EOL;

// but outside of global scope there is a trouble
function f() {
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
}
f();

Expected result:

bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

bool(true)
bool(false)
bool(false)
bool(false)
bool(true)






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

[PHP-BUG] Bug #55493 [NEW]: Superglobal variable variables with ${expression} in non-global scope

2011-08-23 Thread vovan-ve at yandex dot ru 
From: 
Operating system: Windows XP SP3
PHP version:  5.3.7
Package:  Variables related
Bug Type: Bug
Bug description:Superglobal variable variables with ${expression} in non-global 
scope

Description:

ONLY Superglobal variable variables does not work ONLY in non-global
scope and ONLY with non-constant expression. See test script.

I found Req 38527, but it does not describe the problem properly and
due to misunderstanding it has status Feature Request instead of Bug
(and also it is too old).

Test script:
---
// in global scope everything is right
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
echo PHP_EOL;

// but outside of global scope there is a trouble
function f() {
$name = '_SERVER';
var_dump(
isset(${'_SERVER'}),
isset($$name),
isset(${$name}),
isset(${'_SER' . 'VER'}),
isset(${'na' . 'me'})
);
}
f();

Expected result:

bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

Actual result:
--
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)

bool(true)
bool(false)
bool(false)
bool(false)
bool(true)

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

Bug #55061 [Com]: Array autoindex[] overflow

2011-07-29 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=55061&edit=1

 ID: 55061
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Array autoindex[] overflow
 Status: Open
 Type:   Bug
 Package:Arrays related
 Operating System:   WindowsXP SP3
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

No, I have no non-official extensions. I have disabled all extensions for test 
even. May be your int is not int32?


Previous Comments:

[2011-07-27 06:52:24] larue...@php.net

I can not reproduce this warning, do you have non-php-official extension 
installed?

if yes, plz remove them then check again. thanks


[2011-06-29 06:03:07] vovan-ve at yandex dot ru

Sorry for typo. var_dymp == var_dump


[2011-06-29 04:47:05] vovan-ve at yandex dot ru

Description:

There is a test code:

  $a = array(0x7FFF => 42);
  $a[] = 37;
  var_dymp($a);

Second line emits warning:

  Warning: Cannot add element to the array as the next element
  is already occupied in ... on line 2

and doesn't add element with value 37. This is absolutely abnormal
behaviour. At least there is incorrect text for Warning. I expect,
the element should be added with any index (i.e. string "2147483648"
as the result of 0x7FFF+1 thru float), or something else. But
element was not added even.

Test script:
---
$a = array(0x7FFF => 42);
$a[] = 37;
var_dymp($a);

Expected result:

array(1) {
  [2147483647]=>
  int(42)
  ["2147483648"]=>
  int(37)
}

OR (when int will become int64):

array(1) {
  [2147483647]=>
  int(42)
  [2147483648]=>
  int(37)
}

Actual result:
--
Warning: Cannot add element to the array as the next element is already 
occupied in ... on line 2
array(1) {
  [2147483647]=>
  int(42)
}






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

Bug #60006 [Opn]: Array autoindex[] overflow

2011-06-29 Thread vovan-ve at yandex dot ru 
Edit report at https://bugs.php.net/bug.php?id=60006&edit=1

 ID: 60006
 User updated by:vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:Array autoindex[] overflow
 Status: Open
 Type:   Bug
 Package:Arrays related
 Operating System:   WindowsXP SP3
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Sorry for typo. var_dymp == var_dump


Previous Comments:

[2011-06-29 04:47:05] vovan-ve at yandex dot ru

Description:

There is a test code:

  $a = array(0x7FFF => 42);
  $a[] = 37;
  var_dymp($a);

Second line emits warning:

  Warning: Cannot add element to the array as the next element
  is already occupied in ... on line 2

and doesn't add element with value 37. This is absolutely abnormal
behaviour. At least there is incorrect text for Warning. I expect,
the element should be added with any index (i.e. string "2147483648"
as the result of 0x7FFF+1 thru float), or something else. But
element was not added even.

Test script:
---
$a = array(0x7FFF => 42);
$a[] = 37;
var_dymp($a);

Expected result:

array(1) {
  [2147483647]=>
  int(42)
  ["2147483648"]=>
  int(37)
}

OR (when int will become int64):

array(1) {
  [2147483647]=>
  int(42)
  [2147483648]=>
  int(37)
}

Actual result:
--
Warning: Cannot add element to the array as the next element is already 
occupied in ... on line 2
array(1) {
  [2147483647]=>
  int(42)
}






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

[PHP-BUG] Bug #60006 [NEW]: Array autoindex[] overflow

2011-06-29 Thread vovan-ve at yandex dot ru 
From: 
Operating system: WindowsXP SP3
PHP version:  5.3.6
Package:  Arrays related
Bug Type: Bug
Bug description:Array autoindex[] overflow

Description:

There is a test code:

  $a = array(0x7FFF => 42);
  $a[] = 37;
  var_dymp($a);

Second line emits warning:

  Warning: Cannot add element to the array as the next element
  is already occupied in ... on line 2

and doesn't add element with value 37. This is absolutely abnormal
behaviour. At least there is incorrect text for Warning. I expect,
the element should be added with any index (i.e. string "2147483648"
as the result of 0x7FFF+1 thru float), or something else. But
element was not added even.

Test script:
---
$a = array(0x7FFF => 42);
$a[] = 37;
var_dymp($a);

Expected result:

array(1) {
  [2147483647]=>
  int(42)
  ["2147483648"]=>
  int(37)
}

OR (when int will become int64):

array(1) {
  [2147483647]=>
  int(42)
  [2147483648]=>
  int(37)
}

Actual result:
--
Warning: Cannot add element to the array as the next element is already
occupied in ... on line 2
array(1) {
  [2147483647]=>
  int(42)
}

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

[PHP-BUG] Req #52124 [NEW]: [strpos] Limit search inside $haystack by new $length parameter

2010-06-19 Thread vovan-ve at yandex dot ru 
From: 
Operating system: 
PHP version:  Irrelevant
Package:  Strings related
Bug Type: Feature/Change Request
Bug description:[strpos] Limit search inside $haystack by new $length parameter

Description:

Why strpos() does not accept $length parameter with addition to $start? It
would be very useful to search a $needle inside a part of $haystack
sometimes. Now such behaviour can be made by combination with substr():



  $string = 'The big string [with some data here] and with more data
there';

  // searh inside substring from offset 16 with length 19

  $tmp = substr($string, 16, 19);

  // now real search

  $pos = strpos($tmp, 'data');

  if (false !== $pos) $pos += 16; // original position

  var_dump($pos);



It work, but not optimal due to redundant copy of substring. I don't need
this copy, I just want to reduce searching area.

Test script:
---
$string = 'The big string [with some data here] and with more data there';

// search 'data' inside substring from offset 16 with length 19

$pos = strpos($string, 'data', 16, 19);

var_dump($pos);

Expected result:

int(26)


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

Req #51335 [Com]: Search first substring from list

2010-06-11 Thread vovan-ve at yandex dot ru 
Edit report at http://bugs.php.net/bug.php?id=51335&edit=1

 ID:  51335
 Comment by:  vovan-ve at yandex dot ru
 Reported by: vovan-ve at yandex dot ru
 Summary: Search first substring from list
 Status:  Feedback
 Type:Feature/Change Request
 Package: Strings related
 PHP Version: Irrelevant
 Assigned To: kalle

 New Comment:

Yes, such functionality can be done by strpos() foreach needle in the
array. But I see at least two ways to make such search more optimal:

1. Make limit for maximal possible position after which we should not
search a needles. The strpos() has no such limit, so we need to make
substr() after we find next nearest needle.

2. Check length of a next needle and remaining substring to search in.



Of course I can write the function, which do what I need, but I think,
that it won't more optimal in PHP code, then build-in PCRE or build-in
function I request.


Previous Comments:

[2010-06-11 14:21:18] ka...@php.net

I dont think we should add such functionality that already can be done
with a few lines of php code already, combining strpos/stripos with a
foreach and you should get your result:







Dont take that code for granted, as i wrote it on my cell so it might be
buggy, but should show what I mean


[2010-03-20 11:45:58] vovan-ve at yandex dot ru

Description:

If we want to search first substrings from list, we should make multiple
calls to strpos() for each substring. Using PCRE will slowdown
performance. So, we need some new function like:



  int strpos_array(string $haystack, array $needles, string &$found [,
int $offset = 0 ])



which will accept array of substrings in $needle, search first position
of them. If nothing found then returns FALSE. If found any substring
then assign it to $found and return its position.



The function name is not important. Other functions for case-insensitive
search and/or for reverse search (stripos_array, strrpos_array,
strripos_array) also useful.



Extending function strpos() to accept array in $needle is not good due
to &$found parameter.



Good example of using such function is writing parser of some data like
SQL dump. Performance of the function should be higher then PCRE.

Test script:
---
$string = 'foo;bar::baz-qwe';

$search = array('-', ';', '::');

$pos = strpos_array($string, $search, $found, 5);

if ($pos === false) {

echo "Nothing found";

}

else {

echo "Found '$found' at $pos";

}

Expected result:

Found '::' at 7







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

[PHP-BUG] Req #51335 [NEW]: Search first substring from list

2010-03-20 Thread vovan-ve at yandex dot ru 
From: 
Operating system: 
PHP version:  Irrelevant
Package:  Strings related
Bug Type: Feature/Change Request
Bug description:Search first substring from list

Description:

If we want to search first substrings from list, we should make multiple
calls to strpos() for each substring. Using PCRE will slowdown performance.
So, we need some new function like:



  int strpos_array(string $haystack, array $needles, string &$found [, int
$offset = 0 ])



which will accept array of substrings in $needle, search first position of
them. If nothing found then returns FALSE. If found any substring then
assign it to $found and return its position.



The function name is not important. Other functions for case-insensitive
search and/or for reverse search (stripos_array, strrpos_array,
strripos_array) also useful.



Extending function strpos() to accept array in $needle is not good due to
&$found parameter.



Good example of using such function is writing parser of some data like SQL
dump. Performance of the function should be higher then PCRE.

Test script:
---
$string = 'foo;bar::baz-qwe';

$search = array('-', ';', '::');

$pos = strpos_array($string, $search, $found, 5);

if ($pos === false) {

echo "Nothing found";

}

else {

echo "Found '$found' at $pos";

}

Expected result:

Found '::' at 7


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