Bug #62420 [Wfx]: Exception::__toString() creates message in wrong order if prev exception exists
Edit report at https://bugs.php.net/bug.php?id=62420edit=1
ID: 62420
User updated by:bugs dot php at mohiva dot com
Reported by:bugs dot php at mohiva dot com
Summary:Exception::__toString() creates message in wrong
order if prev exception exists
Status: Wont fix
Type: Bug
Package:*General Issues
Operating System: Gentoo Linux
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I think with this behaviour it is really hard to find bugs and it has a huge
WTF factor when you look into your log files and then you see the exception
messages in a reverse order.
Is it really too hard to fix?
Previous Comments:
[2012-07-24 08:28:41] f...@php.net
While you are correct that it might be more logical to reverse the order, this
isn't a huge problem.
[2012-06-26 11:56:09] bugs dot php at mohiva dot com
Description:
The method Exception::__toString() creates the message in the wrong order if a
previous exception exists in the Exception object.
The message contains the message from the previous exception as first and then
marked as next exception the message from the exception object itself. Normally
the message from the current exception should be the first message followed by
the previous message and so one.
Test script:
---
?php
try {
throw new Exception(Previous exception);
} catch (Exception $previous) {
$current = new Exception(Current exception, 0, $previous);
echo 'Previous:' . $current-getPrevious()-getMessage() . 'br /';
echo 'Current:' . $current-getMessage() . 'br /';
echo 'String:' . $current-__toString() . 'br /';
}
Expected result:
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Current exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message
'Previous exception' in exception.php:6 Stack trace: #0 {main}
Actual result:
--
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Previous exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message
'Current exception' in exception.php:6 Stack trace: #0 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62420edit=1
Bug #55544 [Com]: ob_gzhandler always conflicts with zlib.output_compression
Edit report at https://bugs.php.net/bug.php?id=55544edit=1
ID: 55544
Comment by: bugs dot php at mohiva dot com
Reported by:diogin at gmail dot com
Summary:ob_gzhandler always conflicts with
zlib.output_compression
Status: Closed
Type: Bug
Package:Output Control
Operating System: Windows XP SP3 x86
PHP Version:5.4.0alpha3
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
Now, it works for me.
Previous Comments:
[2012-07-24 06:55:04] larue...@php.net
re-fixed agian...
[2012-07-24 06:44:41] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4c1e2bbd6f744b4048d4e0540ecc5dbe005494fe
Log: Re-fix bug #55544
[2012-07-24 06:42:27] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=4c1e2bbd6f744b4048d4e0540ecc5dbe005494fe
Log: Re-fix bug #55544
[2012-07-24 06:17:34] larue...@php.net
here is the confusion(assuming -d output_handler=ob_gzhandler -d
zlib.output_compression=0) :
1. php.output_handler will change the ZLIGB(output_compression) before the zlib
RINIT
2. in zlib RINIT, we set the ZLIBG(output_compression) to default value(ini)
3. if we don't override the ZLIBG(output_compression), then in the
php_zlib_output_compression_start which will be called in RINT will try to
start
zlib compression handler (although it depends on the requeset header), then,
the
conflict warning will be threw.
4. if we override it, then it the php_zlib_output_compression_start, it will
return FALIURE, and no compression occurred(see the codes from my previous
reply)
so, the key problem is multi-featrues depends on one global flag -
ZLIBG(output_compression).
[2012-07-24 05:12:35] larue...@php.net
Here is the problem
ext/zlib/zlib.c
@@ -205,7 +205,7 @@ static int php_zlib_output_handler(void **handler_context,
php_output_context *o
if (SUCCESS ==
php_output_handler_hook(PHP_OUTPUT_HANDLER_HOOK_GET_FLAGS, flags TSRMLS_CC)) {
/* only run this once */
if (!(flags PHP_OUTPUT_HANDLER_STARTED)) {
if (SG(headers_sent) ||
!ZLIBG(output_compression)) {
seems we need a bigger work to resolve this
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=55544
--
Edit this bug report at https://bugs.php.net/bug.php?id=55544edit=1
Bug #55544 [Com]: ob_gzhandler always conflicts with zlib.output_compression
Edit report at https://bugs.php.net/bug.php?id=55544edit=1
ID: 55544
Comment by: bugs dot php at mohiva dot com
Reported by:diogin at gmail dot com
Summary:ob_gzhandler always conflicts with
zlib.output_compression
Status: Feedback
Type: Bug
Package:Output Control
Operating System: Windows XP SP3 x86
PHP Version:5.4.0alpha3
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The error message is gone, but the gzip compression doesn't work no longer.
The configuration that I use in php-fpm.conf is:
php_flag[output_buffering] = on
php_flag[zlib.output_compression] = off
php_value[output_handler] = ob_gzhandler
Can someone of the devs mark the bug 62335 as duplicate.
Previous Comments:
[2012-07-20 18:58:09] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Hi, I've made a fix for this, could you please try with it?
[2012-07-20 18:56:45] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=a6f1533789b897d3b8930b437164e81e0a0f4c72
Log: Fixed bug #55544 (ob_gzhandler always conflicts with
zlib.output_compression)
[2012-07-20 18:56:10] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=a6f1533789b897d3b8930b437164e81e0a0f4c72
Log: Fixed bug #55544 (ob_gzhandler always conflicts with
zlib.output_compression)
[2012-07-20 17:08:24] ras...@php.net
Yes, something isn't being reset after the request when you use
ob_start('ob_gzhandler')
[2012-07-20 08:55:31] webmaster at abyssunderground dot co dot uk
Still present in the recent 5.4.5 update. Very frustrating.
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=55544
--
Edit this bug report at https://bugs.php.net/bug.php?id=55544edit=1
Bug #62335 [Com]: zlib conflict with gzhandler
Edit report at https://bugs.php.net/bug.php?id=62335edit=1
ID: 62335
Comment by: bugs dot php at mohiva dot com
Reported by:hajo at csphere dot eu
Summary:zlib conflict with gzhandler
Status: Assigned
Type: Bug
Package:Zlib related
Operating System: Windows 7
PHP Version:5.4.4
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Same problem here with version 5.4.4 and 5.4.5RC1 from php.net. OS is Centos
6.2, webserver is Apache using PHP via php-fpm.
The configuration that I use in php-fmp.conf is:
php_flag[output_buffering] = on
php_flag[zlib.output_compression] = off
php_value[output_handler] = ob_gzhandler
Previous Comments:
[2012-07-05 07:57:35] dietmar at gps-tour dot info
Hi,
the Bug was fixed by Mike in this commit:
http://git.php.net/?p=php-
src.git;a=commit;h=85a62e9086db7a8ddfcda4ab1279a2439935f8d5
On the 15th of May, the following commit by mike removed the added line by the
above commit:
http://git.php.net/?p=php-
src.git;a=commitdiff;h=0ad53bfd7da12a92a46c08e3fff579a15026b88b
I'not shure, if this was realy intended... So maybe mike can take over this
ticket... Would be great, to have a working ob_gzhandler again in 5.4
[2012-06-21 13:09:17] php at lippe-net dot de
The Error is still there in Debians php 5.4.5-dev.
[2012-06-21 11:57:43] v dot a dot popov at gmail dot com
Seems to be a problem in merging the fix to actual branch, which releases are
made of.
This commit:
http://git.php.net/?p=php-src.git;a=commit;h=85a62e9086db7a8ddfcda4ab1279a2439935f8d5
really fixes the problem, but relevant line is not present in php-5.4.3 and
php-5.4.4.
[2012-06-18 13:39:29] hajo at csphere dot eu
bug 55544 is about this issue, too. between stable php 5.4.0 and 5.4.3 it was
fixed and seems to fail again now.
[2012-06-15 16:31:45] mtanalin at yandex dot ru
Same error for me with this code:
ob_start('ob_gzhandler');
Windows 7, Apache 2.4, PHP 5.4.4 thread-safe, zlib.output_compression is set
to off in php.ini.
The bug disappears if I add php_flag zlib.output_compression off in .htaccess
file of specific host. So, probably, the bug is that global (from php.ini)
zlib.output_compression=off setting is just _ignored_ in PHP 5.4.4.
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=62335
--
Edit this bug report at https://bugs.php.net/bug.php?id=62335edit=1
Bug #55544 [Com]: ob_gzhandler always conflicts with zlib.output_compression
Edit report at https://bugs.php.net/bug.php?id=55544edit=1 ID: 55544 Comment by: bugs dot php at mohiva dot com Reported by:diogin at gmail dot com Summary:ob_gzhandler always conflicts with zlib.output_compression Status: Closed Type: Bug Package:Output Control Operating System: Windows XP SP3 x86 PHP Version:5.4.0alpha3 Assigned To:mike Block user comment: N Private report: N New Comment: Same problem here. This bug isn't fixed in 5.4.5RC1. Previous Comments: [2012-07-02 07:26:54] dietmar at gps-tour dot info Hi, it's not fixed in my PHP Version: 5.4.4-2~dotdeb.0 The Line ZLIBG(output_compression) = 0; in ext/zlib/zlib.c from the obove commit is not in the actual head or 5.4.4 branch anymore. [2012-06-22 13:35:28] ewal at pointpro dot nl You are right. It seems to be fixed in php-5.4.4-1; no more errors now. Thanks. [2012-06-21 11:56:24] v dot a dot popov at gmail dot com Seems to be a problem in merging the fix to actual branch, which releases are made of. This commit: http://git.php.net/?p=php-src.git;a=commit;h=85a62e9086db7a8ddfcda4ab1279a2439935f8d5 really fixes the problem, but relevant line is not present in php-5.4.3 and php-5.4.4. [2012-06-11 22:36:46] php at pointpro dot nl This issue remains on ArchLinux running: PHP 5.4.3 (built: May 31 2012 10:40:02). Even though zlib.output_compression is set to Off in php.ini and phpinfo(); reports this setting as being off, I still get this warning message at each run of any PHP script. Or more specific: PHP Warning: Unknown: output handler 'zlib output compression' conflicts with 'ob_gzhandler' in Unknown on line 0 The same issue happens both when running through lighttpd as when using the CLI. If any more information is required, please let me know which. [2012-04-18 09:48:46] larue...@php.net Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=8f857603b462c123c7b10191c691c0d0f2a6acbc Log: Fixed bug #55544 ob_gzhandler always conflicts with zlib.output_compression 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=55544 -- Edit this bug report at https://bugs.php.net/bug.php?id=55544edit=1
Bug #62419 [Opn]: RuntimeException throws fatal error if passing a previous exception to the ctor
Edit report at https://bugs.php.net/bug.php?id=62419edit=1 ID: 62419 User updated by:bugs dot php at mohiva dot com Reported by:bugs dot php at mohiva dot com Summary:RuntimeException throws fatal error if passing a previous exception to the ctor Status: Open Type: Bug Package:SPL related Operating System: Gentoo Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Hi, if I execute the code through the cli binary then it works as expected. But if I serve the file through apache/php-fpm/fastcgi then PHP behaves as described in the bug report. Cheers, Christian Previous Comments: [2012-06-30 13:36:45] Sjon at hortensius dot net I cannot reproduce this, it seems to work fine? http://3v4l.org/IAF3d#v530 [2012-06-26 11:26:52] bugs dot php at mohiva dot com Description: If you pass a previous exception to the constructor of the RuntimeException class, then PHP throws a fatal error without an error message. I have tested those exceptions which are derived from RuntimeException, and they all work fine. The same counts for the base Exception class. Test script: --- ?php throw new RuntimeException(Exception message, 0, new Exception()); Expected result: Fatal error: Uncaught exception 'RuntimeException' ... on line 3 Actual result: -- Fatal error: in exception.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=62419edit=1
Bug #62419 [Opn]: RuntimeException throws fatal error if passing a previous exception to the ctor
Edit report at https://bugs.php.net/bug.php?id=62419edit=1 ID: 62419 User updated by:bugs dot php at mohiva dot com Reported by:bugs dot php at mohiva dot com Summary:RuntimeException throws fatal error if passing a previous exception to the ctor Status: Open Type: Bug Package:SPL related Operating System: Gentoo Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: If I disable APC for php-fpm then it works as expected. Note: APC is enabled for php-cli and it works as expected. Previous Comments: [2012-07-03 08:23:23] bugs dot php at mohiva dot com Hi, if I execute the code through the cli binary then it works as expected. But if I serve the file through apache/php-fpm/fastcgi then PHP behaves as described in the bug report. Cheers, Christian [2012-06-30 13:36:45] Sjon at hortensius dot net I cannot reproduce this, it seems to work fine? http://3v4l.org/IAF3d#v530 [2012-06-26 11:26:52] bugs dot php at mohiva dot com Description: If you pass a previous exception to the constructor of the RuntimeException class, then PHP throws a fatal error without an error message. I have tested those exceptions which are derived from RuntimeException, and they all work fine. The same counts for the base Exception class. Test script: --- ?php throw new RuntimeException(Exception message, 0, new Exception()); Expected result: Fatal error: Uncaught exception 'RuntimeException' ... on line 3 Actual result: -- Fatal error: in exception.php on line 3 -- Edit this bug report at https://bugs.php.net/bug.php?id=62419edit=1
[PHP-BUG] Bug #62419 [NEW]: RuntimeException throws fatal error if passing a previous exception to the ctor
From: bugs dot php at mohiva dot com Operating system: Gentoo Linux PHP version: 5.4.4 Package: SPL related Bug Type: Bug Bug description:RuntimeException throws fatal error if passing a previous exception to the ctor Description: If you pass a previous exception to the constructor of the RuntimeException class, then PHP throws a fatal error without an error message. I have tested those exceptions which are derived from RuntimeException, and they all work fine. The same counts for the base Exception class. Test script: --- ?php throw new RuntimeException(Exception message, 0, new Exception()); Expected result: Fatal error: Uncaught exception 'RuntimeException' ... on line 3 Actual result: -- Fatal error: in exception.php on line 3 -- Edit bug report at https://bugs.php.net/bug.php?id=62419edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62419r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62419r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62419r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62419r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62419r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62419r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62419r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62419r=needscript Try newer version: https://bugs.php.net/fix.php?id=62419r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62419r=support Expected behavior: https://bugs.php.net/fix.php?id=62419r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62419r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62419r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62419r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62419r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62419r=dst IIS Stability: https://bugs.php.net/fix.php?id=62419r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62419r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62419r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62419r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62419r=mysqlcfg
[PHP-BUG] Bug #62420 [NEW]: Exception::__toString() creates message in wrong order if prev exception exists
From: bugs dot php at mohiva dot com
Operating system: Gentoo Linux
PHP version: 5.4.4
Package: *General Issues
Bug Type: Bug
Bug description:Exception::__toString() creates message in wrong order if prev
exception exists
Description:
The method Exception::__toString() creates the message in the wrong order
if a previous exception exists in the Exception object.
The message contains the message from the previous exception as first and
then marked as next exception the message from the exception object itself.
Normally the message from the current exception should be the first message
followed by the previous message and so one.
Test script:
---
?php
try {
throw new Exception(Previous exception);
} catch (Exception $previous) {
$current = new Exception(Current exception, 0, $previous);
echo 'Previous:' . $current-getPrevious()-getMessage() . 'br /';
echo 'Current:' . $current-getMessage() . 'br /';
echo 'String:' . $current-__toString() . 'br /';
}
Expected result:
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Current exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with
message 'Previous exception' in exception.php:6 Stack trace: #0 {main}
Actual result:
--
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Previous exception' in
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with
message 'Current exception' in exception.php:6 Stack trace: #0 {main}
--
Edit bug report at https://bugs.php.net/bug.php?id=62420edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62420r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62420r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62420r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62420r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62420r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62420r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62420r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62420r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62420r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62420r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62420r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62420r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62420r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62420r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62420r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62420r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62420r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62420r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62420r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62420r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62420r=mysqlcfg
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. Previous Comments: [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. [2006-07-26 16:43:31] w...@php.net (PS: I got here via Bug #37096) 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=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157edit=1
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: I think this bug can be closed. As described by Gustavo(http://news.php.net/php.internals/54999), this is by design. And the wrong results, described in the last comments, are errors in my stream wrapper implementation. Previous Comments: [2011-08-28 10:53:37] bugs dot php at mohiva dot com Do you have further analyzes to provide? Please look at the code at https://gist.github.com/1176512 In this scenario stream_tell gets only be executed internally, after calling stream_fseek. This is the correct behaviour and documented at http://www.php.net/manual/en/streamwrapper.stream-seek.php. As you can see, the first both ftell calls returns a wrong result. Only the last ftell call returns the correct result. [2011-08-26 13:26:58] bugs dot php at mohiva dot com Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. 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=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157edit=1
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: Can you explain why this isn't a bug? In my opinion it's a bug, because the stream_tell method gets never be called in respond to ftell, as it is described in the documentation(http://www.php.net/manual/en/streamwrapper.stream-tell.php). Do you have further analyzes to provide? With the provided code snippet, the behaviour is full reproducible. If this isn't a bug, how can I retrieve the actual file pointer position. For all internal stream protocols it is possible with ftell. Only for the custom implemented protocols it isn't. Maybe I'm wrong or I miss something? Previous Comments: [2011-08-25 12:40:50] paj...@php.net There is no bug but a feature request which seems to be very discutable. Do you have further analyzes to provide? [2011-08-25 12:30:42] bugs dot php at mohiva dot com Two years later the bug is still present in 5.3.8 [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. [2006-07-26 16:43:31] w...@php.net (PS: I got here via Bug #37096) [2006-07-26 16:42:25] w...@php.net I truly hope that this patch didn't get committed; it's not part of the streams design and is fundamentally redundant. I don't have time to make any further commentary than that; further analysis of the user-stream case mentioned in this bug report is required, but it certainly does not require making this kind of change to the core. 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=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157edit=1
Bug #30157 [Com]: ftell() function does not use stream_tell()
Edit report at https://bugs.php.net/bug.php?id=30157edit=1 ID: 30157 Comment by: bugs dot php at mohiva dot com Reported by:tendencies at free dot fr Summary:ftell() function does not use stream_tell() Status: Open Type: Bug Package:Streams related Operating System: * PHP Version:5CVS-2004-09-19 (dev) Block user comment: N Private report: N New Comment: Two years later the bug is still present in 5.3.8 Previous Comments: [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. [2006-07-26 16:43:31] w...@php.net (PS: I got here via Bug #37096) [2006-07-26 16:42:25] w...@php.net I truly hope that this patch didn't get committed; it's not part of the streams design and is fundamentally redundant. I don't have time to make any further commentary than that; further analysis of the user-stream case mentioned in this bug report is required, but it certainly does not require making this kind of change to the core. [2005-06-16 17:22:20] tony2...@php.net Why did you need to add tell() function to the streams internals? Because the original problem (stream_tell() is not used) looks like a bug to me. [2005-06-16 17:17:11] w...@php.net This tell patch (http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff) is wrong; the position should be set implicitly when the stream is opened, and be updated by the streams layer when it knows that it is changed (as happens when you seek). If you need to determine the current position, you simply need to seek with a zero offset from the current position. Why did you need to add tell() function to the streams internals? 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=30157 -- Edit this bug report at https://bugs.php.net/bug.php?id=30157edit=1
[PHP-BUG] Bug #54570 [NEW]: SPLFileObject returns the content of a file after it was deleted
From:
Operating system: Gentoo Linux
PHP version: 5.3.6
Package: SPL related
Bug Type: Bug
Bug description:SPLFileObject returns the content of a file after it was deleted
Description:
With SPLFileObject it is possible to return the content of a file, after
the file was deleted.
Test script:
---
file_put_contents('/tmp/file.txt', 'test');
$file = new SplFileObject('/tmp/file.txt');
unlink('/tmp/file.txt');
var_dump(file_exists('/tmp/file.txt'));
while (!$file-eof()) {
echo $file-fgets();
}
Expected result:
bool(false)
Actual result:
--
bool(false)
test
--
Edit bug report at http://bugs.php.net/bug.php?id=54570edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54570r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54570r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54570r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54570r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54570r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54570r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54570r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54570r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54570r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54570r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54570r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54570r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54570r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54570r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54570r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54570r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54570r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54570r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54570r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54570r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54570r=mysqlcfg
