from:"seld"

Bug #63913 [Fbk-Csd]: Segfault on preg_replace with some weird conditions

2013-01-08 Thread seld

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

 ID: 63913
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:Segfault on preg_replace with some weird conditions
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:PCRE related
 Operating System:   Windows 7 x64
 PHP Version:5.5.0alpha2
-Assigned To:
+Assigned To:seld
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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.

OK the latest snap seems to work indeed, so I am closing this. I will try the 
nest release for sure and hopefully once it trickles down to travis-ci we will 
have a green build again.


Previous Comments:

[2013-01-08 13:58:27] a...@php.net

I've just took the latest 5.5 snap 
http://windows.php.net/downloads/snaps/php-5.5/rcde53e7/ and ran your code 
against it - see no segfaults with CLI. Could you please try this snap?

The trace is kind of a bit too short :) May be you'll have more luck using this 
guide? https://bugs.php.net/bugs-generating-backtrace-win32.php


[2013-01-06 16:01:20] s...@php.net

Regarding the stack limit, I don't think so for two reasons: 1) it works on 
5.4, 2) if you look at the code I tried a very simple .* pattern and that seems 
to trigger a failure too. I tried to increase pcre stuff to 10million and it 
still fails.

As I said I couldn't reduce it further, if I tweak the code too much it stops 
crashing, and I could not really pinpoint it to an exact line that makes it 
fail. All it does is preg_replace calls though so I guess that's it.

Anyway here is the stack trace, not sure it's any help:

Full Call Stack

Function Arg 1 Arg 2 Arg 3 Arg 4   Source 
ntdll!NtRaiseException+12 0094efa4 0094eff4  c005   
 
ntdll!KiUserExceptionDispatcher+29 0094efa4 0094eff4  
c005


Exception Information
PHP5TS!ZEND_DO_FCALL_COMMON_HELPER_SPEC+E7DIn 
php__PID__248__Date__01_06_2013__Time_04_57_23PM__236__Second_Chance_Exception_C005.dmp
 the assembly instruction at php5ts!zend_do_fcall_common_helper_SPEC+e7d in 
c:\Users\seld\Apps\Server\PHP\php\php5ts.dll from The PHP Group has caused an 
access violation exception (0xC005) when trying to read from memory 
location 0x05f804c8 on thread 0


[2013-01-06 10:15:54] paj...@php.net

Can you provide a full BT please? Debug 
symbols must be loaded or the symbol path.

Also I suspect the classic pcre stack limit 
crash issue here. Can you try to increase it 
using edit in and run the test again? If you 
could provide  the simple pcre call, if it us 
actually a pcre crash.


[2013-01-06 00:15:10] s...@php.net

Description:

The composer test suite segfaults on 5.5 as you can see on 
https://travis-ci.org/composer/composer/jobs/3971664

I tried investigating on my machine and could not get to the bottom of it, so 
here are my findings, I hope someone else can reproduce and will have more of a 
clue than I do.

The weirdest thing is that *sometimes* depending on the code changes I make to 
runme.php (see https://gist.github.com/7f465d4109d667a73984) it actually runs 
through fine, but most of the time it crashes. Then a bit later if I try and do 
a similar change it crashes again, either it's an intermittent system issue or 
something's very wrong. Since it also segfaults on travis I would assume the 
latter.

Note that tweaking the input to the preg_replace call (by removing bits and 
pieces of testcase.php) also tends to make it work sometimes. For example 
removing the } at line 15 makes it work for me.


Test script:
---
Run these commands:

git clone https://gist.github.com/7f465d4109d667a73984.git reproduce
cd reproduce/
php runme.php


Expected result:

With 5.4.8 VC9 TS I get the following:

$ php runme.php
string(8) content:
string(103) ?php\n namespace Foo; class StripNoise { public function test() { 
return A\nclass Fail23\n{\n}\nA\n; }
} 
string(4) test
string(2) aa
string(8) starting
string(4) done
bool(true)

Actual result:
--
With 5.5.0-alpha2 V9 TS I get this:

$ php runme.php
string(8) content:
string(103) ?php
 namespace Foo; class StripNoise { public function test() { return A
class Fail23
{
}
A
; } } 
string(4) test

 --- then the process crashes and I get a crash window with the following 
details

Bug #63567 [Fbk-Opn]: exec() always yields a 1 return code

2012-11-27 Thread seld

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

 ID: 63567
 Updated by: s...@php.net
 Reported by:s...@php.net
 Summary:exec() always yields a 1 return code
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Program Execution
 Operating System:   Windows 7 x64
 PHP Version:5.5.0alpha1
 Block user comment: N
 Private report: N



Previous Comments:

[2012-11-21 08:05:30] circus2 at web dot de

It's happening on a Win 7 Home Premium 64Bits running with PHP 5.4.8 VC9 x86 
Thread Safe edition but I can reproduce it with every PHP (5.2, 5.3, 5.5alpha) 
edition.

Unfortunately I have also this weird syntax error.

I have no clue what's going on. I also played with the php-cli.ini, with my 
system 
path and so on.


[2012-11-20 17:57:16] paj...@php.net

Can't reproduce it here.

On which system or PHP version(s) does it happen exactly?


[2012-11-20 16:19:56] s...@php.net

Description:

Running exec() seems to detect a non-zero (and specifically 1) return code/exit 
code for the process. No matter what process. It also affects the proc_open 
class of functions so there is not even a decent workaround as far as we know.

Works on my machine but @johmue on github has the issue consistently. He tried 
with all latest 5.2, 5.3 and 5.4, even 5.5-alpha1. They all do the same. Yet on 
my machine 5.4.8 works fine. At first sight I have exactly the same OS and PHP 
build that he does, so this makes no sense to me. There must be something wrong 
in his environment but we are not able to figure out what causes it.

Note that trying the same thing in the shell directly yields a correct result, 
so the issue seems to be in php, for example this works:

C:\dir
[snip]
C:\echo %errorlevel%
0

You can find the full thread below, but I tried to sum it up above:

https://github.com/composer/composer/issues/613

Test script:
---
C:\php -r exec('dir', $out, $ret);var_dump($ret);


Expected result:

int(0)


Actual result:
--
Die Syntax fÃ¼r den Dateinamen, Verzeichnisnamen oder die 
DatentrÃ¤gerbezeichnung
ist falsch.
int(1)




Interstingly, it does output the wrong return code, and also prints this 
warning saying that the syntax of the filename/command is wrong.






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

Bug #51636 [Fbk]: openssl_random_pseudo_bytes() painfully slow

2011-06-14 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51636edit=1

 ID: 51636
 Updated by: s...@php.net
 Reported by:kaisellgren at gmail dot com
 Summary:openssl_random_pseudo_bytes() painfully slow
 Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   Windows
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

The changelog says this has been fixed in 5.3.4, but the function still takes 
1second to return on my machine (5.3.6). Note that the amount of bytes doesn't 
matter, and it's always around 1second.



$t = microtime(true);

openssl_random_pseudo_bytes(1, $strong);

var_dump(microtime(true) - $t, $strong);



Outputs:

float 1.0317049026489

boolean true


Previous Comments:

[2010-04-23 10:47:16] paj...@php.net

Under CLI or inside a web server?



Can you try under CLI please?


[2010-04-23 10:47:13] paj...@php.net

Under CLI or inside a web server?



Can you try under CLI please?


[2010-04-22 17:38:44] kaisellgren at gmail dot com

Description:

Whenever I execute the following command:



openssl_random_pseudo_bytes(1); // or any other number



PHP will process the function call for like a minute.



I am using Windows 7, and it is affected by both x86 and x64 systems. I do not 
see a problem on Linux, though.

Test script:
---
$random = openssl_random_pseudo_bytes(1, $strong);

Expected result:

The random generation should happen within a blink of an eye.







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

Req #52523 [Csd]: mcrypt_create_iv not reliable on win: Could not gather sufficient random data

2011-06-14 Thread seld

Edit report at http://bugs.php.net/bug.php?id=52523edit=1

 ID: 52523
 Updated by: s...@php.net
 Reported by:php-bugs at thequod dot de
 Summary:mcrypt_create_iv not reliable on win: Could not
 gather sufficient random data
 Status: Closed
 Type:   Feature/Change Request
 Package:mcrypt related
 Operating System:   win32
 PHP Version:5.3.3
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

I'm still experiencing issues with 5.3.6. Calling the method with both  
MCRYPT_DEV_RANDOM and MCRYPT_DEV_URANDOM results in the fatal error. IMO the 
first should block, and the second should just return non-crypto-safe data, but 
it should return *something*, and ideally do it fast.


Previous Comments:

[2010-08-09 10:14:52] paj...@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/.
 
Thank you for the report, and for helping us make PHP better.




[2010-08-09 10:14:16] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302024
Log: - #52523, fix logic (0 is perfectly valid as part of the data, bin data)


[2010-08-03 18:11:15] paj...@php.net

@derick

urandom is not crypto safe (to be more precised).



@thequod

About the patch in typo3, this code is wrong. They use urandom on non windows 
platform, then try alternatives on windows only.



Problem is that they first try COM (very slow), then try with mcrypt_create_iv 
and overwrite COM output (regardless if it worked well or not). MCrypt also 
always exists on windows with 5.3+, no need to test it (statically compiled). 
The openssl code won't be used either (never reached this condition).



However even if the openssl code was used, its logic is wrong. It considers  
non strong (not crypto safe) output as invalid. But urandom is not crypto safe 
anyway. They should test for the openssl function in the 1st place then use 
fopen('urandom') and finally mcrypt and other options. Much better/cleaner.



About your last comment, that fits in the explanation I gave earlier. Nothing 
new.


[2010-08-03 17:47:07] der...@php.net

This is a bug actually. /dev/random is supposed to wait as long as there is 
enough entropy. /dev/urandom cares less (and is a worse source of entropy). The 
behaviour on Windows needs to behave the same as on a Unix.


[2010-08-03 17:07:27] php-bugs at thequod dot de

Windows:

% while php -r '$s = microtime(true); if( mcrypt_create_iv(16, 
MCRYPT_DEV_RANDOM) === false ) exit(1); $e = microtime(true); printf(%.5f\n, 
$e-$s);'; do true; done

0.00449

0.00454



Fatal error: mcrypt_create_iv(): Could not gather sufficient random data in 
Command line code on line 1





Linux:

# while php -r '$s = microtime(true); if( mcrypt_create_iv(16, 
MCRYPT_DEV_RANDOM) === false ) exit(1); $e = microtime(true); printf(%.2f\n, 
$e-$s);'; do true; done

0.00

3.51

3.56

4.03

3.58

4.06

3.71

5.12

4.19

3.41

3.87

3.91

3.74

5.09

4.26

3.71

3.78

4.41

5.48

5.09

6.50

4.14

3.58

3.83

6.02

3.74

3.87

4.68

6.92

4.52

6.01

...



Completely different machines though, of course.




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

http://bugs.php.net/bug.php?id=52523


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

Bug #51636 [Fbk]: openssl_random_pseudo_bytes() painfully slow

2011-06-14 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51636edit=1

 ID: 51636
 Updated by: s...@php.net
 Reported by:kaisellgren at gmail dot com
 Summary:openssl_random_pseudo_bytes() painfully slow
 Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   Windows
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

On 5.3.6, Win7 x64, and it seems on other windows versions as well, the call to 
openssl_random_pseudo_bytes() still takes one second. Since apparently doing 
non-crypto-safe output is not possible on windows, it would be great to at 
least work on the delay for crypto-safe output.


Previous Comments:

[2011-06-14 11:18:05] paj...@php.net

Windows version?


[2011-06-14 10:22:18] s...@php.net

The changelog says this has been fixed in 5.3.4, but the function still takes 
1second to return on my machine (5.3.6). Note that the amount of bytes doesn't 
matter, and it's always around 1second.



$t = microtime(true);

openssl_random_pseudo_bytes(1, $strong);

var_dump(microtime(true) - $t, $strong);



Outputs:

float 1.0317049026489

boolean true


[2010-04-23 10:47:16] paj...@php.net

Under CLI or inside a web server?



Can you try under CLI please?


[2010-04-23 10:47:13] paj...@php.net

Under CLI or inside a web server?



Can you try under CLI please?


[2010-04-22 17:38:44] kaisellgren at gmail dot com

Description:

Whenever I execute the following command:



openssl_random_pseudo_bytes(1); // or any other number



PHP will process the function call for like a minute.



I am using Windows 7, and it is affected by both x86 and x64 systems. I do not 
see a problem on Linux, though.

Test script:
---
$random = openssl_random_pseudo_bytes(1, $strong);

Expected result:

The random generation should happen within a blink of an eye.







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

Req #51879 [Opn]: Add the ability to set the TCP_NODELAY flag for socket streams

2011-02-17 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51879edit=1

 ID: 51879
 Updated by: s...@php.net
 Reported by:suppakilla at gmail dot com
 Summary:Add the ability to set the TCP_NODELAY flag for
 socket streams
 Status: Open
 Type:   Feature/Change Request
 Package:Streams related
 Operating System:   *
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

So.. I attached a patch, but I have not tested it (can't compile on this
machine) and it's also the first time I touch PHP's sources, so given my
little C experience it may very well be incorrect. But I wanted to show
goodwill. Hopefully someone picks this up and implements this small
feature.


Previous Comments:

[2011-02-17 19:44:16] s...@php.net

The following patch has been added/updated:

Patch Name: add-tcp-nodelay
Revision:   1297968256
URL:   
http://bugs.php.net/patch-display.php?bug=51879patch=add-tcp-nodelayrevision=1297968256


[2010-05-24 11:57:52] suppakilla at gmail dot com

In relation to http://bugs.php.net/bug.php?id=46360 I think it would be
useful 

to have the ability to set the TCP_NODELAY flag on socket streams. The
arguments 

for this feature request are basically the same as of #6360, and it
would 

greatly help with performances under certain circumstances when dealing
with 

chatty network protocols.



The following snippet is an example of how the resulting code might look
like in 

a PHP script:



$opts = array(

'socket' = array(

'tcp_nodelay' = false,

),

);

$ctx = stream_context_create($opts);

$stream = stream_socket_client($uri, $errno, $errstr, $timeout, $flags,
$ctx);





Cheers,

Daniele Alessandri


[2010-05-21 15:56:33] suppakilla at gmail dot com

Description:

In relation to http://bugs.php.net/bug.php?id=46360 I think it would be
useful 

to have the ability to set the TCP_NODELAY flag on socket streams. The
arguments 

for this feature request are basically the same as of #6360, and it
would 

greatly help with performances under certain circumstances when dealing
with 

chatty network protocols.



The following snippet is an example of how the resulting code might look
like in 

a PHP script:



$opts = array(

'socket' = array(

'tcp_nodelay' = false,

),

);

$stream = stream_socket_client($uri, $errno, $errstr, $timeout, $flags,
$opts);





Cheers,

Daniele Alessandri







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

Req #51879 [Opn]: Add the ability to set the TCP_NODELAY flag for socket streams

2011-02-17 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51879edit=1

 ID: 51879
 Updated by: s...@php.net
 Reported by:suppakilla at gmail dot com
 Summary:Add the ability to set the TCP_NODELAY flag for
 socket streams
 Status: Open
 Type:   Feature/Change Request
 Package:Streams related
 Operating System:   *
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

So the attached patch should be good now, as you (johannes) said
TCP_NODELAY is used without ifdef [1] already so it should be fine to
use it as is.



Now if I could have php-src karma to commit it myself it'd make my day,
but I guess that's not good enough :)



[1]
http://lxr.php.net/opengrok/xref/PHP_5_3/ext/mysqlnd/mysqlnd_net.c#50


Previous Comments:

[2011-02-17 20:08:25] s...@php.net

The following patch has been added/updated:

Patch Name: add-tcp-nodelay
Revision:   1297969705
URL:   
http://bugs.php.net/patch-display.php?bug=51879patch=add-tcp-nodelayrevision=1297969705


[2011-02-17 19:45:59] s...@php.net

So.. I attached a patch, but I have not tested it (can't compile on this
machine) and it's also the first time I touch PHP's sources, so given my
little C experience it may very well be incorrect. But I wanted to show
goodwill. Hopefully someone picks this up and implements this small
feature.


[2011-02-17 19:44:16] s...@php.net

The following patch has been added/updated:

Patch Name: add-tcp-nodelay
Revision:   1297968256
URL:   
http://bugs.php.net/patch-display.php?bug=51879patch=add-tcp-nodelayrevision=1297968256


[2010-05-24 11:57:52] suppakilla at gmail dot com

In relation to http://bugs.php.net/bug.php?id=46360 I think it would be
useful 

to have the ability to set the TCP_NODELAY flag on socket streams. The
arguments 

for this feature request are basically the same as of #6360, and it
would 

greatly help with performances under certain circumstances when dealing
with 

chatty network protocols.



The following snippet is an example of how the resulting code might look
like in 

a PHP script:



$opts = array(

'socket' = array(

'tcp_nodelay' = false,

),

);

$ctx = stream_context_create($opts);

$stream = stream_socket_client($uri, $errno, $errstr, $timeout, $flags,
$ctx);





Cheers,

Daniele Alessandri


[2010-05-21 15:56:33] suppakilla at gmail dot com

Description:

In relation to http://bugs.php.net/bug.php?id=46360 I think it would be
useful 

to have the ability to set the TCP_NODELAY flag on socket streams. The
arguments 

for this feature request are basically the same as of #6360, and it
would 

greatly help with performances under certain circumstances when dealing
with 

chatty network protocols.



The following snippet is an example of how the resulting code might look
like in 

a PHP script:



$opts = array(

'socket' = array(

'tcp_nodelay' = false,

),

);

$stream = stream_socket_client($uri, $errno, $errstr, $timeout, $flags,
$opts);





Cheers,

Daniele Alessandri







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

Bug #51184 [Fbk-Csd]: DateInterval has incorrect days property on windows

2010-05-19 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51184edit=1

 ID:   51184
 Updated by:   s...@php.net
 Reported by:  s...@php.net
 Summary:  DateInterval has incorrect days property on windows
-Status:   Feedback
+Status:   Closed
 Type: Bug
 Package:  Date/time related
 Operating System: Windows
 PHP Version:  5.3.2RC3
-Assigned To:  
+Assigned To:  seld

 New Comment:

Confirmed working here. Kalle's comment came after 5.3.2 and I thought
the commit was younger too, but it seems good in 5.3.2 indeed.


Previous Comments:

[2010-05-19 11:43:47] paj...@php.net

It has been released, so try 5.3.2


[2010-05-19 11:38:49] pluk77 at gmail dot com

There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.


[2010-03-25 13:26:21] ka...@php.net

Please try using this snapshot:

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

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

Derick fixed #49778, did that fix the issue?


[2010-03-02 13:41:41] s...@php.net

Description:

On Windows, no matter what the dates are, the days property of the
DateInterval object returned by DateTime::diff() is always 6015.



Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081

Test script:
---
$start = new DateTime('2010-06-06'); 

$end   = new DateTime('2011-02-04'); 

echo $start-diff($end)-days;



$start = new DateTime('2005-01-01'); 

echo $start-diff($end)-days;

Expected result:

The right number of days, or at least always 42 :)

Actual result:
--
6015, always.






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

Bug #51184 [Csd]: DateInterval has incorrect days property on windows

2010-05-19 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51184edit=1

 ID:   51184
 Updated by:   s...@php.net
 Reported by:  s...@php.net
 Summary:  DateInterval has incorrect days property on windows
 Status:   Closed
 Type: Bug
 Package:  Date/time related
 Operating System: Windows
 PHP Version:  5.3.2RC3
 Assigned To:  seld

 New Comment:

Can you try with VC9? Works here on latest VC9 Non Thread Safe


Previous Comments:

[2010-05-19 15:20:33] pluk77 at gmail dot com

I am using this version:



PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08)



and the bug still shows.



Can anybody else confirm this bug is still open?


[2010-05-19 11:54:18] s...@php.net

Confirmed working here. Kalle's comment came after 5.3.2 and I thought
the commit was younger too, but it seems good in 5.3.2 indeed.


[2010-05-19 11:43:47] paj...@php.net

It has been released, so try 5.3.2


[2010-05-19 11:38:49] pluk77 at gmail dot com

There seems to be no windows snapshot available so unable to test if the
bugfix solved this problem as well.


[2010-03-25 13:26:21] ka...@php.net

Please try using this snapshot:

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

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

Derick fixed #49778, did that fix the issue?




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

http://bugs.php.net/bug.php?id=51184


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

Bug #51184 [Csd-ReO]: DateInterval has incorrect days property on windows

2010-05-19 Thread seld

Edit report at http://bugs.php.net/bug.php?id=51184edit=1

 ID:   51184
 Updated by:   s...@php.net
 Reported by:  s...@php.net
 Summary:  DateInterval has incorrect days property on windows
-Status:   Closed
+Status:   Re-Opened
 Type: Bug
 Package:  Date/time related
 Operating System: Windows
-PHP Version:  5.3.2RC3
+PHP Version:  5.3.2
-Assigned To:  seld
+Assigned To:  pajoye



Previous Comments:

[2010-05-19 16:20:08] s...@php.net

VC6 NTS fails as well here. VC9 NTS works.


[2010-05-19 15:45:07] pluk77 at gmail dot com

Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug
while the VC9 does not.


[2010-05-19 15:22:51] s...@php.net

Can you try with VC9? Works here on latest VC9 Non Thread Safe


[2010-05-19 15:20:33] pluk77 at gmail dot com

I am using this version:



PHP5.3.2 VC6 x86 Thread Safe (2010-Mar-04 20:11:08)



and the bug still shows.



Can anybody else confirm this bug is still open?


[2010-05-19 11:54:18] s...@php.net

Confirmed working here. Kalle's comment came after 5.3.2 and I thought
the commit was younger too, but it seems good in 5.3.2 indeed.




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

http://bugs.php.net/bug.php?id=51184


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

#48387 [Asn]: ArrayObject and properties serialization

2010-02-28 Thread seld

 ID:   48387
 Updated by:   s...@php.net
 Reported By:  david at grudl dot com
 Status:   Assigned
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.2.9
 Assigned To:  colder
 New Comment:

For what it's worth, the reproduce code works perfectly fine with
php5.3.0


Previous Comments:


[2009-05-25 15:46:56] david at grudl dot com

Description:

In PHP 5.2.x there are not serialized any public/protected/private
properies of ArrayObject descendants.



Reproduce code:
---
class Test extends ArrayObject
{
public $var;
}

$test = new Test;
$test-var = 'hello';
$dolly = unserialize(serialize($test));
echo $dolly-var;

Expected result:

- hello

Actual result:
--
none





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

#49333 [Com]: Bug in recursive regex processing

2009-08-25 Thread j dot boggiano at seld dot be

 ID:   49333
 Comment by:   j dot boggiano at seld dot be
 Reported By:  inf3rno dot hu at gmail dot com
 Status:   Open
 Bug Type: PCRE related
 Operating System: Windows XP
 PHP Version:  5.2.10
 New Comment:

I am not entirely sure what you are trying to achieve so maybe I broke
some functionality, but with this pattern at least it gives the expected
result with \r\n or \n (of course \n has less chars..)

$pattern='%\s*(?:([a-z])(?:.*?(?:(?R).*?)*?\1)?|$)%sD';

Is that good enough ?


Previous Comments:


[2009-08-25 08:35:43] j...@php.net

When the $test contains \r\n instead of \n it fails. 



[2009-08-24 12:21:40] inf3rno dot hu at gmail dot com

I reproduced it on another computer with the latest WAMPServer (Apache
2.2.11, PHP 5.3.0). I copied the code from here.



[2009-08-24 11:20:39] inf3rno dot hu at gmail dot com

Yes, I can reproduce it.
Tried with alternative text editor, but same result. So I think it's
not memory or text editor problem. (Btw. I'll test my computer's memory
soon.)
I'll try it out after a reinstall, maybe some dll files are damaged.



[2009-08-23 10:54:45] sjo...@php.net

Could not reproduce. When I run the code example you supplied, I get
the expected result. Are you sure you have submitted the right code
example?



[2009-08-23 08:10:45] inf3rno dot hu at gmail dot com

Description:

I developed a recursive regex pattern for compile template patterns.
During the tests I found this bug. I managed to restrict it to the
following piece of code.
The count of the numbers, and every character (\n too) counts. So if I
have 11+ characters long string in the 'y'-s block, then it's buggy, but
by 10- character long strings it works fine.
I hope it's a real bug, and not a damage in my computer. :-)

Reproduce code:
---
$pattern='%.*?(?:([a-z])(?:.*?(?:(?R).*?)*?\1)?|$)%sD';
$test='
x
0123456789
x
y
01234567890
y';
preg_match_all($pattern,$test,$matches,PREG_SET_ORDER);
var_dump($matches);

Expected result:

array(3) { [0]=  array(2) { [0]=  string(18)  x 0123456789 x [1]= 
string(1) x } [1]=  array(2) { [0]=  string(19)  y 01234567890 y
[1]=  string(1) y } [2]=  array(1) { [0]=  string(0)  } } 

Actual result:
--
array(0) { } 





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

#44043 [NEW]: Enforcing a method without specifying the arguments

2008-02-04 Thread j dot boggiano at seld dot be

From: j dot boggiano at seld dot be
Operating system: Windows/Linux
PHP version:  6CVS-2008-02-04 (snap)
PHP Bug Type: Class/Object related
Bug description:  Enforcing a method without specifying the arguments

Description:

The purpose of this is to allow an abstract class or an interface to
enforce the implementation of a method, without however enforcing the
arguments signature.

This is -as I understand it- not a bug, but a feature request.

Reproduce code:
---
/***
 * This works in PHP5 but does not anymore in PHP6
 */
class Parnt {
public function foo() {}
}
class Child extends Parnt {
public function foo($arg){}
}

/***
 * Those don't work in either 5 or 6
 */
abstract class Abst {
abstract public function foo();
}
class Child2 extends Abst {
public function foo($arg){}
}

interface Int {
public function foo();
}
class Child3 implements Int {
public function foo($arg){}
}

Expected result:

/***
 * Proposal for a solution
 */
abstract class AbstFixed {
abstract public function foo;
}
class Child4 extends AbstFixed {
public function foo($arg){}
}

// = Declaring the method without parenthesis (which currently throws a
parse error) would allow the implementations of this method to use any
argument signature they please.

Actual result:
--
At the moment those three examples throw a fatal error in PHP6 with :
Declaration of Child::foo() must be compatible with that of Parnt::foo()

I don't think it is a bug, but I think having the capability to allow
variable function signatures would definitely be a plus, especially with
PHP6 coming that prevents the first example to work.

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

#44043 [Opn]: Enforcing a method without specifying the arguments

2008-02-04 Thread j dot boggiano at seld dot be

 ID:   44043
 User updated by:  j dot boggiano at seld dot be
 Reported By:  j dot boggiano at seld dot be
 Status:   Open
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  6CVS-2008-02-04 (snap)
 New Comment:

As I understand it, the following example would work, right ?

interface Foo {
function bar(...);
}
class Baz implements Foo {
function bar($first, $second, $third, $whatever) {}
}

If so, it's exactly what I'm looking for, your syntax is as good as
mine as far as I'm concerned. In fact it's even better as it allows for
a partial signature enforcement while still leaving the argument list
opened.


Previous Comments:


[2008-02-04 20:27:32] [EMAIL PROTECTED]

What we could do is adding '...'. That way you can do stuff like:

interface Foo {
  function bar($first, ...);
}

Now all classes that derive from Foo must implement the same function
protocol, for instance:

class Baz {
  function bar($first, ...) {}
}

Anything else would violate the inheritance rules.



[2008-02-04 18:44:46] j dot boggiano at seld dot be

Description:

The purpose of this is to allow an abstract class or an interface to
enforce the implementation of a method, without however enforcing the
arguments signature.

This is -as I understand it- not a bug, but a feature request.

Reproduce code:
---
/***
 * This works in PHP5 but does not anymore in PHP6
 */
class Parnt {
public function foo() {}
}
class Child extends Parnt {
public function foo($arg){}
}

/***
 * Those don't work in either 5 or 6
 */
abstract class Abst {
abstract public function foo();
}
class Child2 extends Abst {
public function foo($arg){}
}

interface Int {
public function foo();
}
class Child3 implements Int {
public function foo($arg){}
}

Expected result:

/***
 * Proposal for a solution
 */
abstract class AbstFixed {
abstract public function foo;
}
class Child4 extends AbstFixed {
public function foo($arg){}
}

// = Declaring the method without parenthesis (which currently throws
a parse error) would allow the implementations of this method to use any
argument signature they please.

Actual result:
--
At the moment those three examples throw a fatal error in PHP6 with :
Declaration of Child::foo() must be compatible with that of
Parnt::foo()

I don't think it is a bug, but I think having the capability to allow
variable function signatures would definitely be a plus, especially with
PHP6 coming that prevents the first example to work.





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

Bug #63913 [Fbk-Csd]: Segfault on preg_replace with some weird conditions

Bug #63567 [Fbk-Opn]: exec() always yields a 1 return code

Bug #51636 [Fbk]: openssl_random_pseudo_bytes() painfully slow

Req #52523 [Csd]: mcrypt_create_iv not reliable on win: Could not gather sufficient random data

Bug #51636 [Fbk]: openssl_random_pseudo_bytes() painfully slow

Req #51879 [Opn]: Add the ability to set the TCP_NODELAY flag for socket streams

Req #51879 [Opn]: Add the ability to set the TCP_NODELAY flag for socket streams

Bug #51184 [Fbk-Csd]: DateInterval has incorrect days property on windows

Bug #51184 [Csd]: DateInterval has incorrect days property on windows

Bug #51184 [Csd-ReO]: DateInterval has incorrect days property on windows

#48387 [Asn]: ArrayObject and properties serialization

#49333 [Com]: Bug in recursive regex processing

#44043 [NEW]: Enforcing a method without specifying the arguments

#44043 [Opn]: Enforcing a method without specifying the arguments

14 matches

Site Navigation

Mail list logo

Footer information