[PHP-DOC] #35555 [Opn-Fbk]: [chm] bug on function.stream-context-create.html
ID: 3 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at bandvulc dot co dot uk -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: windows PHP Version: Irrelevant New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. No such text appears on this page. Did you see it in a (now absent) user contributed note perhaps? Previous Comments: [2005-12-05 13:50:41] richard dot quadling at bandvulc dot co dot uk Description: I have found a bug on page function.stream-context-create.html [chm date: 2005-12-01]... The new parameter max_redirects limits the number of redirects to 20. It is unclear if, without this value set, or for versions of PHP which this setting is inappropriate, if redirects are followed forever or at all; 0 or infinity. As this setting only LIMITS the redirects, it does not control whether to follow them or not, though NOT can be implemented by setting the value to 0. I tried looking at the source (quick search in LXR first) and could find no reference to max_redirects, though I did find CURLOPT_MAXREDIRS in the CURL extension. I did a search on request_fulluri (the setting immediately before max_redirects in the manual) and this was found in http_fopen_wrapper.c I then did a check for php_stream_context_get_option and none of the finds related to the HTTP protocol with the max_redirects option and considering this is now settable by a user, I was expecting this to be the case. From what I can tell, the 20 is hard-coded and cannot be altered by setting max_redicts in the context. -- Edit this bug report at http://bugs.php.net/?id=3edit=1
[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
Updated by: [EMAIL PROTECTED]
Reported By: joh at deworks dot net
Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
Previous Comments:
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
[PHP-DOC] #31919 [Opn]: E_STRICT errors are passed to custom error handler
ID: 31919
Updated by: [EMAIL PROTECTED]
Reported By: joh at deworks dot net
Status: Open
Bug Type: Documentation problem
Operating System: Linux
PHP Version: Irrelevant
New Comment:
It all depends on how you define consistent...
The E_STRICT gets passed on to a custom error handler if the custom
error handler is defined when it's thrown. Currently all E_STRICT
errors are thrown at compile time, for the main page compilation
happens before the set_error_handler() can ever be called. For the
included files this (may) be after the error handler is defined.
Additionally, future E_STRICT errors may be thrown at run time so you
could even see them in a main file at some point.
Lastly, it doesn't make sense to go out of the way to forcibly mask
errors when they can be caught.
If you want to avoid it in your own code, just use the optional second
parameter to set_error_handler() and make the behavior match your
definition of consistency.
Previous Comments:
[2005-02-11 15:54:58] joh at deworks dot net
How can this be a documentation problem when the script behaves as
expected, and as documented, when the code triggering the E_STRICT
appears inside the same file as the set_error_handler() call, but not
when it is included from another file? What we have here is conflicting
behaviour, and updating the documentation is not going to fix it
(because E_STRICT errors are not handled by a custom error handler when
they appear in the same file as the set_error_handler()).
[2005-02-11 08:11:34] [EMAIL PROTECTED]
I appreciate your reasoning behind labeling it as a scripting engine
problem, but the solution really lies in updating the documentation.
Good analysis of the root cause though.
[2005-02-10 21:18:13] joh at deworks dot net
Description:
E_STRICT errors are passed to a custom error handler when the errors
appear in an included file.
The documentation for set_error_handler() clearly states that The
following error types cannot be handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and E_STRICT.
This is true, if the error occurs in the same file as the error
handler, but when a file which triggers an E_STRICT warning is
included, PHP passes the error to the custom error handler. As this
only happens when including an erroneous file, I'm reporting this bug
as a Scripting Engine problem, and not a Documentation problem.
I've tested this on the latest 5.1.0 (200502101130) development
snapshot.
Reproduce code:
---
errorhandler.php:
?php
function errorHandler($severity, $message, $file = null, $line = null,
$context = array())
{
static $severityMap = array(
E_ERROR = 'E_ERROR',
E_WARNING = 'E_WARNING',
E_PARSE = 'E_PARSE',
E_NOTICE= 'E_NOTICE',
E_CORE_ERROR= 'E_CORE_ERROR',
E_CORE_WARNING = 'E_CORE_WARNING',
E_COMPILE_ERROR = 'E_COMPILE_ERROR',
E_COMPILE_WARNING = 'E_COMPILE_WARNING',
E_USER_ERROR= 'E_USER_ERROR',
E_USER_WARNING = 'E_USER_WARNING',
E_USER_NOTICE = 'E_USER_NOTICE',
E_STRICT= 'E_STRICT'
);
echo 'strong' . __METHOD__ . ': PHP Error with severity ' .
$severityMap[$severity] . '(' . $severity . ') raised: ' . $message .
/strongbr /;
}
set_error_handler('errorHandler');
include 'strict.php';
?
strict.php:
?php
class Foo {
public function __construct() { }
public function Foo() { }
}
?
Expected result:
Strict Standards: Redefining already defined constructor for class Foo
in strict.php on line 4
Actual result:
--
errorHandler: PHP Error with severity E_STRICT(2048) raised: Redefining
already defined constructor for class Foo
--
Edit this bug report at http://bugs.php.net/?id=31919edit=1
[PHP-DOC] #29045 [Sus]: gzopen for URL
ID: 29045
Updated by: [EMAIL PROTECTED]
Reported By: fcartegnie at nordnet dot fr
Status: Suspended
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.3.6
Assigned To: pollita
New Comment:
Wez needs to chime in on this...
I stated that it wouldn't work for http (with or without the patch)
because I thought we had disabled shrinking the chunk_size to 1 while
reading into the HTTP headers (for performance reasons). Looking back
at the code I see that the temporary shift into small chuck sizes *IS*
enabled when the STREAM_WILL_CAST flag is set (which it is for the zlib
fopen wrapper).
Maybe it was the conditional set based on the option flag that was the
compromise... in which case I'd say: Go ahead and use
fopen('compress.zlib://http://blah...',... but the patch provided for
gzopen() seems completely unnecessary.
Previous Comments:
[2004-07-07 16:16:46] [EMAIL PROTECTED]
compress.zlib://http://host.file.gz should work fine in php 4, not?
include compress.zlib://file.php.gz; works too ;-)
[2004-07-07 16:12:31] [EMAIL PROTECTED]
compress.zlib://host/path isn't actually valid.
What is valid however (as of PHP5) is:
$fp = fopen('http://host/path/file.gz', 'r');
/* Maybe a small fread() here to consume gzip headers, I don't recall
if they're sent with deflated content */
stream_filter_append($fp, 'zlib.inflate');
Note: For PHP 5.0 you need PECL package zlib_filter, it'll be rolled
into the core in PHP 5.1 .
The patch supplied above needs further review as I see a big potential
for zlib stream errors with the read buffer blocks that come in with
the headers.
[2004-07-07 14:39:51] fcartegnie at nordnet dot fr
compress.zlib://http:// seems to work
Maybe we could add some deprecation/pointer info in the documentation
of gzopen()
Changing for documentation problem
[2004-07-07 14:33:40] fcartegnie at nordnet dot fr
I did not see this syntax in the documentation.
fopen(compress.zlib://host.com/file.gz)
How would you specify HTTP or FTP ?
[2004-07-07 13:09:46] [EMAIL PROTECTED]
Why not use fopen(compress.zlib://host.com/file.gz) and all the other
normal file operations?
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/29045
--
Edit this bug report at http://bugs.php.net/?id=29045edit=1
[PHP-DOC] #28497 [Opn-Csd]: Disabling allow_url_fopen via httpd.conf has no effect
ID: 28497 Updated by: [EMAIL PROTECTED] Reported By: iwonderiftheyllpostthistoapublicnewsgrou -Status: Open +Status: Closed -Bug Type: PHP options/info functions +Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.6 New Comment: The documentation was incorrect. allow_url_fopen is meant to be a security feature for allowing the system administrator to completely prohibit the use of url fopen wrappers. To allow it to be overridden with a simple ini_set() would negate that purpose. The documentation sources have been updated to read PHP_INI_SYSTEM and should show as such in the next build of the online manual. Previous Comments: [2004-05-23 21:15:32] iwonderiftheyllpostthistoapublicnewsgrou Description: To improve security against poor coding I wish to disable allow_url_fopen by default and allow users who have a legitimate need for it to enable it themselves via use of .htaccess or ini_set(). Given that allow_url_fopen is listed as PHP_INI_ALL in the docs I thought this would be relatively easy, however I am unable to make it work: Having allow_url_fopen off in php.ini disables it completely - the user cannot activate it via .htaccess or ini_set(). So I tried to use php_flag allow_url_fopen off in my httpd.conf to turn it off by default. However this has no effect at all and users can happily use URL-fopen functions without turning it on. Using php_admin_flag instead of php_flag disables it entirely as if set via php.ini. There appears to be no middle-ground here that lets the user control use of this function instead of everybody or nobody having access. Reproduce code: --- httpd.conf -- php_flag allow_url_fopen off test.php ?php echo phere is file:/p; readfile(http://www.r1ch.net/ohno;); ini_set (allow_url_fopen, 1); echo phere is more file:/p; readfile(http://www.r1ch.net/ohno;); ? Expected result: here is file: Warning: readfile(): URL file-access is disabled in the server configuration in /.../test.php on line 2 here is more file: ohno Actual result: -- here is file: ohno here is more file: ohno -- Edit this bug report at http://bugs.php.net/?id=28497edit=1
[PHP-DOC] #27855 [Opn-Bgs]: setting up a constant with a value retrieved by a function
ID: 27855 Updated by: [EMAIL PROTECTED] Reported By: blackei2k at gmx dot de -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.5 New Comment: Actually you can. What you can't do is define() (read redefine) a constant more than once. That's why it's called a constant. Previous Comments: [2004-04-03 15:49:53] blackei2k at gmx dot de Description: You can't define a constant using define(), and automatically assign a value to it, that is of a function. Reproduce code: --- ?php define(E_SQL, mysql_error(), true); ? Expected result: E_SQL should now contain the last error-string. (Of course only if there was an error). Actual result: -- It's empty -- Edit this bug report at http://bugs.php.net/?id=27855edit=1
[PHP-DOC] #27829 [Opn-Csd]: Incorrect Paths Specified
ID: 27829 Updated by: [EMAIL PROTECTED] Reported By: barkcomp at chariot dot net dot au -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win32 PHP Version: 5.0.0RC1 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2004-04-01 22:34:49] barkcomp at chariot dot net dot au Description: Install.txt specifies that php5apache.dll should be loaded from c:\php\sapi\php5apache, when infact it resides in c:\php\, caused me some confusion for a few minutes - apache complaining it couldn't find the right file(s) -- Edit this bug report at http://bugs.php.net/?id=27829edit=1
[PHP-DOC] #27806 [Opn-Bgs]: get_class() no longer returns lowercase name
ID: 27806 Updated by: [EMAIL PROTECTED] Reported By: jcalvert at gmx dot net -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 5.0.0RC1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This was an intended change. Previous Comments: [2004-03-31 12:52:20] [EMAIL PROTECTED] This is expected behavior, but should be documented. Making it a documentation bug. [2004-03-31 12:48:18] jcalvert at gmx dot net Description: The documented behavior for get_class() is to return the classname in lowercase for user-defined classes. After switching to PHP5.0.0RC1 the function returns the name in the original case, causing minor compatibility issues. -- Edit this bug report at http://bugs.php.net/?id=27806edit=1
[PHP-DOC] #27806 [Bgs-Opn]: get_class() no longer returns lowercase name
ID: 27806 Updated by: [EMAIL PROTECTED] Reported By: jcalvert at gmx dot net -Status: Bogus +Status: Open Bug Type:Documentation problem PHP Version: 5.0.0RC1 New Comment: Sorry, didn't see you mark it for Documentation. Previous Comments: [2004-03-31 13:32:42] [EMAIL PROTECTED] 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 This was an intended change. [2004-03-31 12:52:20] [EMAIL PROTECTED] This is expected behavior, but should be documented. Making it a documentation bug. [2004-03-31 12:48:18] jcalvert at gmx dot net Description: The documented behavior for get_class() is to return the classname in lowercase for user-defined classes. After switching to PHP5.0.0RC1 the function returns the name in the original case, causing minor compatibility issues. -- Edit this bug report at http://bugs.php.net/?id=27806edit=1
[PHP-DOC] #27210 [Asn]: SERVER_BIND in stream_socket_server manual page on the wrong place
ID: 27210 Updated by: [EMAIL PROTECTED] Reported By: glox at glox dot be Status: Assigned Bug Type:Documentation problem -PHP Version: Irrelevant +PHP Version: 5.0.0-CVS-HEAD Assigned To: nlopess New Comment: Sorry, I was asleep at the wheel on that one. You're absolutely right. Good catch. Not sure why nlopess took assignment rather than simply *doing* the fix, but if he's listening... Don't worry about verifying it. glox is right, swap that param down to the other example! Previous Comments: [2004-02-10 11:32:33] glox at glox dot be Description: The STREAM_SERVER_BIND flag in the stream_socket_server() manual page is with the tcp socket example. However the udp socket requires this flag. This flag was added in the manual page due to my previous bug report, but I think it's added in the wrong example. The STREAM_SERVER_BIND flag should be moved to the second example. -- Edit this bug report at http://bugs.php.net/?id=27210edit=1
[PHP-DOC] #27065 [Csd]: stream_socket_server won't listen on udp sockets
ID: 27065
Updated by: [EMAIL PROTECTED]
Reported By: glox at glox dot be
Status: Closed
Bug Type: Documentation problem
Operating System: freeBSD 5.1
PHP Version: 5CVS-2004-01-27 (dev)
New Comment:
It'd be nice, but because of the way the transports layer operates it
won't happen without making exceptions on a per protocol basis and
that's gernerally not a good idea.
As to the documentation, the source has been updated, but the online
manual is only rebuilt from source on a periodic basis.
The change amounts to:
$server = stream_socket_server('udp://0.0.0.0:13/', $errno, $errstr,
STREAM_SERVER_BIND);
Previous Comments:
[2004-01-28 13:06:20] glox at glox dot be
Isn't it better to let php define those flags then, based on the socket
type (udp/tcp).
I don't see any change in the example either ...
[2004-01-27 23:27:55] [EMAIL PROTECTED]
udp:// sockets should not attempt to listen(). Because
stream_socket_server() uses both the bind and listen flags by default
you need to explicitly set them to bind only.
I've fixed the example to reflect this.
[2004-01-27 21:29:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Seems to work for me.
[2004-01-27 16:02:25] otoria at freecode dot nl
Same problem:
[EMAIL PROTECTED] ~$ uname -a
Linux serenity 2.4.20 #2 Mon Mar 17 22:02:15 PST 2003 i686
unknown
[EMAIL PROTECTED] ~$ php -v
PHP 5.0.0RC1-dev (cli) (built: Jan 26 2004 16:41:55)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2004 Zend
Technologies
[EMAIL PROTECTED] ~$
[2004-01-27 15:57:32] glox at glox dot be
The port is open, and I run this script as root
[EMAIL PROTECTED] /share/wolfd# sockstat | grep 27961
[EMAIL PROTECTED] /share/wolfd#
[EMAIL PROTECTED] /share/wolfd# whoami
root
[EMAIL PROTECTED] /share/wolfd#
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/27065
--
Edit this bug report at http://bugs.php.net/?id=27065edit=1
[PHP-DOC] #27065 [Fbk-Csd]: stream_socket_server won't listen on udp sockets
ID: 27065
Updated by: [EMAIL PROTECTED]
Reported By: glox at glox dot be
-Status: Feedback
+Status: Closed
-Bug Type: Sockets related
+Bug Type: Documentation problem
Operating System: freeBSD 5.1
PHP Version: 5CVS-2004-01-27 (dev)
New Comment:
udp:// sockets should not attempt to listen(). Because
stream_socket_server() uses both the bind and listen flags by default
you need to explicitly set them to bind only.
I've fixed the example to reflect this.
Previous Comments:
[2004-01-27 21:29:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Seems to work for me.
[2004-01-27 16:02:25] otoria at freecode dot nl
Same problem:
[EMAIL PROTECTED] ~$ uname -a
Linux serenity 2.4.20 #2 Mon Mar 17 22:02:15 PST 2003 i686
unknown
[EMAIL PROTECTED] ~$ php -v
PHP 5.0.0RC1-dev (cli) (built: Jan 26 2004 16:41:55)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2004 Zend
Technologies
[EMAIL PROTECTED] ~$
[2004-01-27 15:57:32] glox at glox dot be
The port is open, and I run this script as root
[EMAIL PROTECTED] /share/wolfd# sockstat | grep 27961
[EMAIL PROTECTED] /share/wolfd#
[EMAIL PROTECTED] /share/wolfd# whoami
root
[EMAIL PROTECTED] /share/wolfd#
[2004-01-27 15:53:21] glox at glox dot be
Description:
When trying to listen on a udp socket in freebsd with php5, php fails
to create the socket and returns unknown error.
The manual page gives an example about a udp server, however this
returns the same error.
Operating system (uname -a):
FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
PHP version (php -v):
PHP 5.0.0RC1-dev (cli) (built: Jan 16 2004 22:47:26)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2004 Zend Technologies
PHP configure line:
./configure --with-mysql=/usr/local/mysql --with-mime-magic
--with-apxs=/usr/local/sbin/apxs --enable-wddx --with-zlib
--enable-bcmath --with-bz2 --with-ncurses --enable-cli --disable-cgi
--with-gd --with-jpeg-dir --with-png-dir --with-zlib-dir
--with-calender --enable-pcntl --enable-sysvsem --enable-sysvshm
--enable-sysvmsg --enable-exif --enable-sockets --with-xpm-dir
--with-gettext --with-gmp --enable-mbstring --with-xmlrpc --with-xsl
--with-ex --enable-openssl
Reproduce code:
---
?php
$sock = stream_socket_server('udp://0.0.0.0:27961');
?
Expected result:
No output
Actual result:
--
Warning: stream_socket_server(): unable to connect to
udp://0.0.0.0:27961 (Unknown error) in /share/wolfd/serv.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=27065edit=1
[PHP-DOC] #26390 [Opn-Csd]: buggy example
ID: 26390 Updated by: [EMAIL PROTECTED] Reported By: corinl at gmx dot de -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: It always has been changed. See CVS. Previous Comments: [2003-11-25 10:11:00] [EMAIL PROTECTED] As the behavior of gzpassthru changed, the docs for this func should be updated. [2003-11-24 18:36:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Thanks... gzpassthru()'s behavior changed slightly with the introduction of streams. The next build of the manual will have it showing an explicit gzclose(); [2003-11-24 16:47:01] corinl at gmx dot de Description: http://www.php.net/manual/en/ref.zlib.php In Example 1, there is a missing gzclose($zp); before the unlink. When the example is run as is it cannot unlink the tmp file because it is still open. -- Edit this bug report at http://bugs.php.net/?id=26390edit=1
[PHP-DOC] #26390 [Csd]: buggy example
ID: 26390 Updated by: [EMAIL PROTECTED] Reported By: corinl at gmx dot de Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: s/always/already/ Previous Comments: [2003-11-25 14:12:46] [EMAIL PROTECTED] It always has been changed. See CVS. [2003-11-25 10:11:00] [EMAIL PROTECTED] As the behavior of gzpassthru changed, the docs for this func should be updated. [2003-11-24 18:36:30] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Thanks... gzpassthru()'s behavior changed slightly with the introduction of streams. The next build of the manual will have it showing an explicit gzclose(); [2003-11-24 16:47:01] corinl at gmx dot de Description: http://www.php.net/manual/en/ref.zlib.php In Example 1, there is a missing gzclose($zp); before the unlink. When the example is run as is it cannot unlink the tmp file because it is still open. -- Edit this bug report at http://bugs.php.net/?id=26390edit=1
[PHP-DOC] #26390 [Opn-Csd]: Zlib Example has Error
ID: 26390 Updated by: [EMAIL PROTECTED] Reported By: 6b5bq27x02 at sneakemail dot com -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Thanks... gzpassthru()'s behavior changed slightly with the introduction of streams. The next build of the manual will have it showing an explicit gzclose(); Previous Comments: [2003-11-24 16:47:01] 6b5bq27x02 at sneakemail dot com Description: http://www.php.net/manual/en/ref.zlib.php In Example 1, there is a missing gzclose($zp); before the unlink. When the example is run as is it cannot unlink the tmp file because it is still open. -- Edit this bug report at http://bugs.php.net/?id=26390edit=1
[PHP-DOC] #26374 [Opn-Bgs]: http://www.ovrimos.com/ mentioned is Documentation is an erotica stories site
ID: 26374 Updated by: [EMAIL PROTECTED] Reported By: v_santhanam at amrita dot edu -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Thank you for reporting this, however it has already been reported and fixed in the manual's CVS repository. The fix will show in the next documentation build. Previous Comments: [2003-11-23 21:38:48] v_santhanam at amrita dot edu Description: http://www.ovrimos.com/ mentioned is Documentation is an erotica stories site. Please rectify it. The URL is http://www.php.net/manual/en/ref.ovrimos.php -- Edit this bug report at http://bugs.php.net/?id=26374edit=1
[PHP-DOC] #25821 [Opn-Csd]: Function checkdnsrr() does not suppor AAAA type
ID: 25821 Updated by: [EMAIL PROTECTED] Reported By: ktak at nsk dot ru -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. That was probably my fault :o Previous Comments: [2003-10-10 10:06:04] ktak at nsk dot ru Description: Online documentation of function checkdnsrr() has record that type is applicable from version 4.3.0. But type is absent in PHP 4.3.0 and PHP 4.3.3, but it is presented in PHP 5. Reproduce code: --- // http://www.php.net/manual/en/function.checkdnsrr.php ? echo checkdnsrr(something, ); ? [2003-10-10 10:03:43] ktak at nsk dot ru Description: Online documentation of function checkdnsrr() has record that type is applicable from version 4.3.0. But type is absent in PHP 4.3.0 and PHP 4.3.3, but it is presented in PHP 5. Reproduce code: --- http://www.php.net/manual/en/function.checkdnsrr.php -- Edit this bug report at http://bugs.php.net/?id=25821edit=1
[PHP-DOC] #25611 [Opn-Bgs]: my first and only complaint about php
ID: 25611 Updated by: [EMAIL PROTECTED] Reported By: h3 at mindkind dot org -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: slackware PHP Version: 4.3.3 New Comment: In that case, I'm happy to say you have no complaints about PHP. The inavailability of other formats is a temporary problem which we're working on resolving. As for XML availability, you can download the sources of the PHP manual (which are in Docbook XML format) from CVS. CVSROOT=:pserver:[EMAIL PROTECTED]:/repository Password=phpfi Module=phpdoc Previous Comments: [2003-09-19 18:08:22] h3 at mindkind dot org Description: Hi, As I was using php more and more I decided to install linux, wich is the basic supported operating system for apache, php and all the rest. How surprised I was today when I wanted to download the php doc .. wich was only available in a non-linux friendly and hugly format .. CHM . what kind of a joke it is ? I ASK. Even xml would have been a way better choice. This is the first and hopefully the last brick that I'd trow to the php communauty. what's the next step ? ms wordperfect ? I think that this offline documentation is a shame to the great language that php is (I'm clearly not pointing the online refference tho). h3 -- Edit this bug report at http://bugs.php.net/?id=25611edit=1
[PHP-DOC] #25459 [Csd-Bgs]: expressions, echo/return and strings
ID: 25459
Updated by: [EMAIL PROTECTED]
Reported By: blackei2k at gmx dot de
-Status: Closed
+Status: Bogus
Bug Type:Documentation problem
PHP Version: 4.3.2
New Comment:
Nice to see you again philip, but this bug is 'Bogus'.
Previous Comments:
[2003-09-09 18:47:08] [EMAIL PROTECTED]
This is also in the faq:
http://www.php.net/manual/en/faq.using.php#faq.using.wrong-order
[2003-09-09 17:21:05] kennyt at kennyt dot com
and that really should be 'td' and 'tdhaha/td' :-)
[2003-09-09 17:19:15] kennyt at kennyt dot com
function foo()
{
echo foo;
}
this should be
function foo() {
return 'foo';
}
that's why your output isn't within the td/ tag.
[2003-09-09 13:35:32] blackei2k at gmx dot de
Description:
I'm using the ternary operator which calls a function. The output is
not there where it should be, but a few liens above. I don't get any
errors.
Reproduce code:
---
function foo()
{
echo foo;
}
...
while($obj = mysql_fetch_object($result)){
echo ($obj-id == $id ? td.foo()./td : tdhaha/td);
}
Expected result:
that the output is where it should be.
i'm listing rows and only in one row ($obj-id == $id) is true.
the output of foo can be found dozens of lines above from where it
should be.
--
Edit this bug report at http://bugs.php.net/?id=25459edit=1
[PHP-DOC] #22988 [Asn-Csd]: I'm feeling lucky - rand() bug
ID: 22988 Updated by: [EMAIL PROTECTED] Reported By: vakmajom at freemail dot hu -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.3.2RC1 Assigned To: pollita New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-05-11 08:36:09] [EMAIL PROTECTED] changing to the correct status [2003-05-06 14:29:26] vakmajom at freemail dot hu Why it is a Windows bug? Because RAND_MAX is not 2147483647? Alrigth then. But the documentation should also mention that you must not call rand(min, max) or mt_rand(min, max) if (max-min 2147483647) (on unix systems you get a Warning message (tested with PHP 4.1.0), but on Windows systems mt_rand(-2147483648, 2147483647) simply returns -2147483648, without any warning message - as I explained. [2003-04-26 16:56:07] [EMAIL PROTECTED] Actually the docs should mention this. Reclassifying and opening back up. [2003-04-26 16:55:38] [EMAIL PROTECTED] After discussion it looks like PHP won't be getting into the business of fixing windows bugs :) As you suggested the best bet is to stick with mt_rand() to get the resulution you're looking for. [2003-04-18 00:03:55] [EMAIL PROTECTED] I can see where you were going with that, unfortunately it has the unexpected result of simply chaning the bug so that only *odd* numbers get returned I'm still thinking over this one and hope you give it some more thought too :) 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/22988 -- Edit this bug report at http://bugs.php.net/?id=22988edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #25063 [Opn-Csd]: ftp_site docs ambiguous
ID: 25063
Updated by: [EMAIL PROTECTED]
Reported By: gilem at wsg dot net
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.3.3RC3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
I've added the following example as well as a See Also link to
ftp_raw() which acts the way your reproduce code was expecting
ftp_site() to act.
?php
/* Connect to FTP server */
$conn = ftp_connect('ftp.example.com');
if (!$conn) die('Unable to connect to ftp.example.com');
/* Login as user with password pass */
if (!ftp_login($conn, 'user', 'pass')) die('Error logging into
ftp.example.com');
/* Issue: SITE CHMOD 0600 /home/user/privatefile command to ftp
server */
if (ftp_site($conn, 'CHMOD 0600 /home/user/privatefile')) {
echo Command executed successfully.\n;
} else {
die('Command failed.');
}
?
Previous Comments:
[2003-08-12 15:38:28] gilem at wsg dot net
Description:
http://us4.php.net/manual/en/function.ftp-site.php
the docs do not specify that the SITE command is not supposed to be
included in the second argument.
This could be qualified with an example.
ftp_site( $conn_id, CHMOD 755 filename );
Reproduce code:
---
ftp_site( $conn_id, SITE CHMOD 755 filename );
fails since it sends
SITE SITE...
to the server.
--
Edit this bug report at http://bugs.php.net/?id=25063edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24269 [Opn-Bgs]: str_replace doesn't accept forth param in 4.3.2.
ID: 24269 Updated by: [EMAIL PROTECTED] Reported By: bking at starbridgesystems dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: WinXP PHP Version: 4.3.2 New Comment: That's because the fourth parameter isn't available until PHP 5.0. Direct from the manual: --- Note: As of PHP 5.0 the number of matched and replaced needles will be returned in count which is passed by reference. --- Previous Comments: [2003-06-20 11:32:54] [EMAIL PROTECTED] Currently from the manual: Note: As of PHP 5.0 the number of matched and replaced needles will be returned in count which is passed by reference. This eludes to the fact that the parameter exists since PHP 5.0.0 but can be made clearer. Reclassified-docbug. [2003-06-20 11:28:04] bking at starbridgesystems dot com Description: The str_replace funtion doesn't accept the forth parameter in 4.3.2. The documentation says it will accept four parameters. We need to fix one or the other. Reproduce code: --- C:\PHP432php -q ? echo str_replace(dumb,dumber,dumb dumb dumb,$count); ? ^Z br / bNotice/b: Undefined variable: count in bC:\PHP432\-/b on line b1/b br / br / bWarning/b: Wrong parameter count for str_replace() in bC:\PHP432\-/b o n line b1/bbr / -- Edit this bug report at http://bugs.php.net/?id=24269edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21646 [Opn-Csd]: Strftime: negative timestamps
ID: 21646 Updated by: [EMAIL PROTECTED] Reported By: wolfandreas at yahoo dot de -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-06-08 17:37:22] mog at nospam dot please I'm having this problem on Redhat 7.3/PHP4.3.2 On our forum software (vBulletin) members profiles are showing Dec-31-1969 for people born before 1970. [2003-02-25 23:54:21] [EMAIL PROTECTED] Please do not use all for the OS field unless you know for certain that it affects all platforms equally. Most of the datetime related functions (strftime included) are dependent on what support exists in the libraries on the running system. An example of this variable behavior is the time() function which returns values from -2147483648 to 2147483647 on most unix platforms, but only returns positive values under windows. On your platform, strftime() only accepts positive values. That is not to say that strftime only accepts positive values on all platforms. Have you tried date()? The strftime manual page already has a warning stating that not all format specifiers are supported on all platforms, perhaps that should be extended to warn of inconsistent support for timestamp values. [2003-01-14 23:16:48] wolfandreas at yahoo dot de Situation: The function strftime does return false for negative unix-timestamps. Problem: The functions mktime and strtotime return negative values for dates before 1970-01-01 00:00 UT. Many users try something like: strftime($format,strtotime($date_before_1970)) and wonder why this does not work. If the behavior for timestamps before second 0 (start of Jan 1., 1970 UT) is undefined why do all other time functions return negative values ? The documentation for strftime does not say anything about negative values for timestamps, too. Solution: Let strftime return values (Gregorian calendar) for negative timestamps. (Perhaps there should be a warning ?) [2003-01-14 23:13:46] wolfandreas at yahoo dot de Situation: The function strftime does return false for negative unix-timestamps. Problem: The functions mktime and strtotime return negative values for dates before 1970-01-01 00:00 UT. Many users try something like: strftime($format,strtotime($date_before_1970)) and wonder why this does not work. If the behavior for timestamps before second 0 (start of Jan 1., 1970 UT) is undefined why do all other time functions return negative values ? The documentation for strftime does not say anything about negative values for timestamps, too. Solution: Let strftime return values (Gregorian calendar) for negative timestamps. (Perhaps there should be a warning ?) -- Edit this bug report at http://bugs.php.net/?id=21646edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22942 [Opn]: bcpow
ID: 22942 Updated by: [EMAIL PROTECTED] Reported By: aleon at sedesa dot com dot ar Status: Open -Bug Type: BC math related +Bug Type: Documentation problem Operating System: linux 2.4.18 PHP Version: 4.3.1 New Comment: libbcmath, unfortunately, does not support non-integer exponents in either raise (bcpow) or raisemod (bcpowmod). libgmp, sadly, is no better. Documentation should be updated to reflect. Previous Comments: [2003-03-28 15:51:18] aleon at sedesa dot com dot ar bcpow(1.018333,0.9990867579) this gives 1 when it should be 1.018316438, no matter wich scale i choose. If you approach 0.9990867579 to 0.9, then it works. './configure' '--with-mysql' '--with-gd' '--with-zlib' '--with-apxs' --enable-bcmath P3 500 mhz, 256 ram -- Edit this bug report at http://bugs.php.net/?id=22942edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22609 [Opn-Fbk]: Index
ID: 22609 Updated by: [EMAIL PROTECTED] Reported By: aldiab at softbyte dot qc dot ca -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: Windows XP home PHP Version: 4.3.1 New Comment: Could you be more specific in what you mean by an 'index'? http://www.php.net/manual/en/ is one type of index (a table of contents). http://www.php.net/quickref.php is another type of index (a listing of all documented functions). Previous Comments: [2003-03-08 10:46:46] aldiab at softbyte dot qc dot ca It would be nice to have an index for the php manual. Thank you. -- Edit this bug report at http://bugs.php.net/?id=22609edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22445 [Opn-Csd]: getmxrr() and RFC 974
ID: 22445
Updated by: [EMAIL PROTECTED]
Reported By: jjones at aene dot ma dot cx
-Status: Open
+Status: Closed
-Bug Type: Feature/Change Request
+Bug Type: Documentation problem
Operating System: Linux/GNU
PHP Version: 4.3.1
New Comment:
Jim's comments on closing Bug #12385 are valid, however this does bear
additional documentation. Reclassifying and closing as I've just
updated the manual to reflect.
Previous Comments:
[2003-02-26 15:05:39] jjones at aene dot ma dot cx
This report is the same as bug #12385, but with getmxrr()'s real-world
implementation it seems to need reconsideration. The only email
address validation on many sites == whether or not getmxrr() returns
TRUE.
I'm not too concerned with the politics of who should handle this
behavior, but with the usage of getmxrr() for address verification
purposes in the PHP world, I don't believe it should wait for the
appropriate fixes in the appropriate locations.
You can find an amateur fix for this behavior at
http://aene.ma.cx/php-4.3.1-getmxrr.diff
From RFC 974 ... It is possible that the list of MXs in the response to
the query will be empty. This is a special case. If the list is empty,
mailers should treat it as if it contained one RR, an MX RR with a
preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its
only MX). In addition, the mailer should do no further processing on
the list, but should attempt to deliver the message to REMOTE. The
idea here is that if a domain fails to advertise any information about
a particular name we will give it the benefit of the doubt and attempt
delivery.
getmxrr() returns FALSE when the MX list is empty. The simple code
below can be used for verification.
if ( getmxrr( php.net, $array ) ) { var_dump( $array ); }
if ( getmxrr( aene.ma.cx, $array ) ) { var_dump( $array ); }
--
Edit this bug report at http://bugs.php.net/?id=22445edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22400 [Opn-Csd]: mktime does not permit negative values under windows. This is not documented.
ID: 22400 Updated by: [EMAIL PROTECTED] Reported By: alan at frostick dot com -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: WIN32 PHP Version: 4.3.1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-02-24 12:53:16] alan at frostick dot com PHP Manual (version 13-01-2003) Warning: mktime() [function.mktime.html]: Windows does not support negative values for this function This is not noted in the referenced manual page, in fact examples of how it can be used are given instead. Presumably Windows users need a test like: if (PHP_OS==WIN32) code_your_own_mktime(...); // when negative values are to be used else mktime(...);// Unix is OKAY with negative values :-) from your friendly code_your_own dept... -- Edit this bug report at http://bugs.php.net/?id=22400edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21646 [Opn]: Strftime: negative timestamps
ID: 21646 Updated by: [EMAIL PROTECTED] Reported By: wolfandreas at yahoo dot de Status: Open -Bug Type: Feature/Change Request +Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: Please do not use all for the OS field unless you know for certain that it affects all platforms equally. Most of the datetime related functions (strftime included) are dependent on what support exists in the libraries on the running system. An example of this variable behavior is the time() function which returns values from -2147483648 to 2147483647 on most unix platforms, but only returns positive values under windows. On your platform, strftime() only accepts positive values. That is not to say that strftime only accepts positive values on all platforms. Have you tried date()? The strftime manual page already has a warning stating that not all format specifiers are supported on all platforms, perhaps that should be extended to warn of inconsistent support for timestamp values. Previous Comments: [2003-01-14 23:16:48] wolfandreas at yahoo dot de Situation: The function strftime does return false for negative unix-timestamps. Problem: The functions mktime and strtotime return negative values for dates before 1970-01-01 00:00 UT. Many users try something like: strftime($format,strtotime($date_before_1970)) and wonder why this does not work. If the behavior for timestamps before second 0 (start of Jan 1., 1970 UT) is undefined why do all other time functions return negative values ? The documentation for strftime does not say anything about negative values for timestamps, too. Solution: Let strftime return values (Gregorian calendar) for negative timestamps. (Perhaps there should be a warning ?) [2003-01-14 23:13:46] wolfandreas at yahoo dot de Situation: The function strftime does return false for negative unix-timestamps. Problem: The functions mktime and strtotime return negative values for dates before 1970-01-01 00:00 UT. Many users try something like: strftime($format,strtotime($date_before_1970)) and wonder why this does not work. If the behavior for timestamps before second 0 (start of Jan 1., 1970 UT) is undefined why do all other time functions return negative values ? The documentation for strftime does not say anything about negative values for timestamps, too. Solution: Let strftime return values (Gregorian calendar) for negative timestamps. (Perhaps there should be a warning ?) -- Edit this bug report at http://bugs.php.net/?id=21646edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Re: preg_replace() docs need expliot warning
While I'm..*grossly* against the /e switch (or eval()s in general) at
all (and its use with tainted sources even moreso), I realize my whinning
and moaning isn't going to change the fact /e and eval() exist and are used.
But here's a thought...
How about a /E switch to preg_replace which would function like /e except
that it temporarily enables safe_mode. Similarly eval() could be extended
with a second parameter that does the same. I realize safe_mode is
generally intended for sysadmins to protect themselves from malicious
content authors, but why not use this functionality at the content level to
protect from malicious clients?
There *might* be a need to have an eval.* version of the safe_mode ini
options to specify how much is (dis)allowed when in eval-safe_mode. I
havn't thought through the implications of doing this, but it seems worth
exploring.
-Pollita
Cross-Posting to php-dev
James E. Flemer [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Just one more example. Even when using double quotes, it
is possible to execute code:
?php
$a = '___! ${`rm -rf /tmp/sess_*`} !___';
$b = preg_replace(/!(.*)!/e, print(\\\1\);, $a);
?
Again, assume $a comes from a tainted source.
-James
On Mon, 3 Feb 2003, James E. Flemer wrote:
A warning about preg_replace() command needs to be added to
the docs page for this command. The preg_replace() command
can use the /e modifier to have the replacement be
eval()d by PHP, just like perl.
There is a high potential for exploitable PHP code if a
programmer uses the /e modifier and does not use quotes
around the back references (backrefs). Without quotes,
arbitrary commands may be executed by using the backtick
operator. Other commands may be executed as well, but are
more difficult, since addslashes() prevents the characters
['\\\0] from being used.
An clear and explicit warning should be added to the doc
page for preg_replace, indicating the backrefs must always
be quoted. Single quotes are preferable, since double
quotes allow variable expansion.
See the messages below for examples of how this may be
exploited. (Assume that $a comes from an untrusted source,
i.e. a get/post/cookie/header variable.)
-James
-- Forwarded message --
Date: Mon, 3 Feb 2003 01:04:23 -0500 (EST)
From: James E. Flemer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] preg_replace oddity [exploitable]
I found a more evil example:
?php
$a = ___! `rm -rf /tmp/sess_*` !___;
$b = preg_replace(/!(.*)!/e, print(\\1);, $a);
?
This happily executes rm -rf /tmp/sess_*. I will not
give out more examples, but if one examines the code for
addslashes() it is quite obvious what you can an cannot do
here. Thus it is clearly a Bad Thing for someone to use
preg_replace with the /e modifier and not use quotes around
the \\n or $n backrefs.
The docs should be updated to include a very noticeable
warning about this hole. I am contemplating possible
solutions for this problem...
Also as a side note, it does not seem to be possible to use
'echo' as part of the expression, print must be used. (Yes
I know why, just pointing it out.)
-James
On Thu, 30 Jan 2003, James E. Flemer wrote:
Can someone explain what is going on here:
--- foo.php ---
?php
$a = ___! 52); echo(42 !___;
$b = preg_replace(/!(.*)!/e, print(\\1);, $a);
print(\n---\na: $a\nb: $b\n);
?
--- end ---
--- output ---
52
---
a: ___! 52); echo(42 !___
b: ___1___
--- end ---
I understand that one is supposed to use single quotes
around the \\1 in the above preg_replace. But what happens
when they do not? Clearly the echo(42); is not executed,
and it is not printed by print(). Even more interesting is
if you put something like echo(\42 in $a, then you get a
bunch of errors including:
Fatal error - Failed evaluating code:
print( 52); echo(\42 );
It seems like preg_replace() is doing some strange things,
and might be something that could be exploitable if a
remote user can supply the first argument, and the second
argument does not enclose \\n options.
-James
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] cvs: phpdoc /en/reference/array/functions array-splice.xml array-unique.xml
Damien, Did you run 'make test' on this? It's got several syntactic errors. -Pollita + Cela va afficher : I'm convinced it's your life mission to force English speakers to learn French. :) Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21980 [Opn]: gmdate CUT - UCT typo
ID: 21980 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: - PHP Version: 4.3.0 New Comment: I thought it was UTC (Universal Time Coordinae) -- Spoken with a french accent. Previous Comments: [2003-01-31 06:53:07] [EMAIL PROTECTED] php documentation for function gmdate states: gmdate -- Format a GMT/CUT date/time This should however probably be: gmdate -- Format a GMT/UCT date/time Typo in UCT (CUT). :) -- Edit this bug report at http://bugs.php.net/?id=21980edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20204 [Opn-Csd]: $var_classname::function(); returns a parse error. You need to use eval().
ID: 20204 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed -Bug Type: Feature/Change Request +Bug Type: Documentation problem Operating System: Linux PHP Version: 4.2.3 New Comment: As you state, this calling convention is not supported. The reason relates to how the Zend engine parses PHP syntax and will not change in the forseeable future. However, there is cleaner way to accomplish what you're attempting without using eval(). Try: return call_user_func(array($varclassname,'function')); I notice that the documentation for call_user_func fails to note the ability to call static class methods in this way(changing category to documentation problem) and have added an additional paragraph and explanation explaining this. Previous Comments: [2002-10-31 15:37:27] [EMAIL PROTECTED] The comma `:' in the first line of code is supposed to be a double comma `::' [2002-10-31 15:34:41] [EMAIL PROTECTED] Using $var_classname:function(); throws up a parse error. This was probably not a feature intended to be included rather than a bug. Currently I have a workaround using this: print eval(return .$var_classname.::function();); Would like to see it implemented in a future version if possible :) -- Edit this bug report at http://bugs.php.net/?id=20204edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21816 [Bgs-Asn]: preg_replace has problem with arrays
ID: 21816 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Assigned -Bug Type: *Regular Expressions +Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.0 -Assigned To: +Assigned To: pollita New Comment: This could be made more clear in the manual. I'll add a note and an example tonight. Previous Comments: [2003-01-22 14:52:19] [EMAIL PROTECTED] 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 The replacment is done in the order the array was created, if you want it to be done based on array keys that run an appropriate sorting function before executing the preg_replace function. [2003-01-22 12:14:45] [EMAIL PROTECTED] The search strings used in the preg_replace() function are regular expressions. [abc] is a regular expression which matches any of the characters a, b or c. Either use str_replace() to replace your strings, or learn to use regular expressions http://de3.php.net/manual/en/pcre.pattern.syntax.php. [2003-01-22 08:41:20] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string2 = preg_replace($search,$replace,$string); echo Result is:BR . $string2; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // if you add a ksort it works fine: ksort($search,SORT_NUMERIC); ksort($replace,SORT_NUMERIC); reset($search); reset($replace); $string3 = preg_replace($search,$replace,$string); echo BRBRCorrected (ksort) Result is:BR . $string3; // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? [2003-01-22 07:43:39] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit this bug report at http://bugs.php.net/?id=21816edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21816 [Asn-Csd]: preg_replace has problem with arrays
ID: 21816 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: Windows XP PHP Version: 4.3.0 Assigned To: pollita New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-22 15:30:10] [EMAIL PROTECTED] This could be made more clear in the manual. I'll add a note and an example tonight. [2003-01-22 14:52:19] [EMAIL PROTECTED] 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 The replacment is done in the order the array was created, if you want it to be done based on array keys that run an appropriate sorting function before executing the preg_replace function. [2003-01-22 12:14:45] [EMAIL PROTECTED] The search strings used in the preg_replace() function are regular expressions. [abc] is a regular expression which matches any of the characters a, b or c. Either use str_replace() to replace your strings, or learn to use regular expressions http://de3.php.net/manual/en/pcre.pattern.syntax.php. [2003-01-22 08:41:20] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string2 = preg_replace($search,$replace,$string); echo Result is:BR . $string2; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // if you add a ksort it works fine: ksort($search,SORT_NUMERIC); ksort($replace,SORT_NUMERIC); reset($search); reset($replace); $string3 = preg_replace($search,$replace,$string); echo BRBRCorrected (ksort) Result is:BR . $string3; // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? [2003-01-22 07:43:39] [EMAIL PROTECTED] ?php // Hi, while using the following code i experienced // an interesting behaviour of preg_replace(): $string = Say a [word0] about [word1] and [word2]; $search[0] =[word0]; $search[1]= [word1]; $search[2]= [word2]; $replace[0]=betterWord0; $replace[2]=betterWord2; $replace[1]=betterWord1; $string = preg_replace($search,$replace,$string); echo Result is:BR . $string; echo BRBRResult should be:BR Say a [betterWord0] about [betterWord1] and [betterWord2]; // result should be: //Say a [betterWord0] about [betterWord1] and [betterWord2] // // but produces: //Say a [betterWord0] about [betterWord2] and [betterWord1] // // Seems like the order in which i build my array // is the order for replacing...and not the index // of $array[$index] // // // Has someone an idea, about what's happening here? // // just a guy addicted to php ;-) ? -- Edit this bug report at http://bugs.php.net/?id=21816edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21833 [Fbk]: IIS 5.0 requires additional parameters on Add Mappings Tab
ID: 21833 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: Windows 2000 Server PHP Version: 4.3.0 New Comment: I have *NOT* experienced this requirement with PHP installed as a CGI on my Win2K/IIS5.0 installation. (I just have c:\php\php.exe entered in my IIS5.0 setup). Some research needs to be done to determine when and why it is necessary. Previous Comments: [2003-01-22 22:34:30] [EMAIL PROTECTED] Is this modification specific to (required for) IIS 5 and not IIS 4? Even so, does adding it still allow IIS 4 to work with PHP CGI? This %s %s information appears in the user comments as well but needs to be put in the manual :) [2003-01-22 22:15:54] [EMAIL PROTECTED] Sorry, I forgot to include URL: http://aspn.activestate.com//ASPN/Reference/Products/ActivePerl/faq/Windows/ActivePerl-Winfaq6.html Link: How do I configure Microsoft IIS 4.0/IIS 5.0 to support Perl [2003-01-22 22:07:42] [EMAIL PROTECTED] ?php phpinfo(); ? This line produced the No input file output after I configured PHP on IIS 5.0 by following each step of installation instructions (I decided to configure PHP to work as a CGI script, not SAPI ) After several tries I understood what the problem is. I have an experience in Perl programming under Linux and Windows and I remembered that Active Perl 5.6 installation script adds not only the script name in Add/Edit Application Extension Mapping dialog but also adds %s %s to the end. Quote from the ActiveState Perl installation docs: To run Perl as a CGI application, type the full path to Perl.exe followed by %s %s. When a script is executed, the first %s will be replaced by the full path to the script, and the second %s will be replaced by the script parameters. This applies only to CGI mode. For ISAPI mode there is no need in these additional %s %s at the end. So I suggest that installation guide may be corrected like this: --- text --- Windows NT/2000/XP and IIS 4 or newer and PWS 4 on NT Workstation or W2K non server editions --- text --- If you want to use the CGI binary, do the following: Under 'Home Directory', 'Virtual Directory', or 'Directory', click on the 'Configuration' button, and then enter the App Mappings tab. Click Add, and in the Executable box, type: c:\php\php.exe %s %s (assuming that you have unzipped PHP in c:\php\). --- text --- And thats it! Here is also a URL to ActiveState website where I found the explanation for this %s spells :-))) Well, this is it. Everything else is working fine! Denys Vorobyov -- Edit this bug report at http://bugs.php.net/?id=21833edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #15166 [Opn-Csd]: preg_replace issue when \\1 is followed by 1
ID: 15166
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: WINDOWS 2000
PHP Version: 4.1.1
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-01-24 11:32:30] [EMAIL PROTECTED]
'{$1}' or {\$1}
[2002-01-24 11:27:17] [EMAIL PROTECTED]
I tried the syntax {$1} with PHP 4.1.1 as below:
1/
$test=preg_replace(/(\!DOCTYPE\s+map\s+SYSTEM\s+\http:\/\/)[^\/]+/i,{$1}$servname:$servport,$test);
It gives me the following error:
Parse error: parse error, expecting `T_VARIABLE' or `'$'' in
C:\inetpub\wwwroot\bug2.php on line 33
2/ Escaping the first brace:
$test=preg_replace(/(\!DOCTYPE\s+map\s+SYSTEM\s+\http:\/\/)[^\/]+/i,\{$1}$servname:$servport,$test);
The result is the following one:
test2 RESULT :{!DOCTYPE map SYSTEM
http://}10.0.9.91:81/Gui/dtd/deployment/dbmap.dtd;
It is escaping properly the 1 contained in $servername but keep the
braces.
3/ The only way I found to escape $servername is by using the value 99
as follow:
$test=preg_replace(/(\!DOCTYPE\s+map\s+SYSTEM\s+\http:\/\/)[^\/]+/i,\\1\\99$servname:$servport,$test);
991 is not taken because of the limitation to 99 different strings. I
just need to make sure I am not using 99 different parentheses which is
pretty huge.
[2002-01-22 17:26:53] [EMAIL PROTECTED]
You'd either need to escape the number after your reference, ie: \\1\1
or if you're using PHP 4.0.4 or later, you can use {$1} in the
replacement portion of preg_replace (see documentation).
[2002-01-22 15:00:59] [EMAIL PROTECTED]
What do you think about the following suggestions:
A/ Counting how many string are enclosed by parentheses.
preg_replace(/(..)test()/,\\110.0.0.173,$test);
= expecting 2 strings enclosed
Then parse the value following \\ and keep only the one lower than the
max expected.
Expecting 2:
\\1 OK
\\11 TOO high, keep \\1
I do not know what the impact might be in term of performance.
= Implementing a way to escape might be faster.
B/ Using a different notation to escape the string following \\1 (brace
for example)
preg_replace(/(..)test()/,\\{1}10.0.0.173,$test);
Thanks for your prompt answer, that was quick :-)
[2002-01-22 14:44:12] [EMAIL PROTECTED]
\\11 matches the 11th string enclosed by parenthesis.
Can't find anything about escaping it. Reclassified as a documentation
problem.
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/15166
--
Edit this bug report at http://bugs.php.net/?id=15166edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18705 [Opn-Csd]: More info in strstr()
ID: 18705
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.2.2
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-08-03 06:38:51] [EMAIL PROTECTED]
Attention : Keep in mind that when you want whether there is substring
into string it is better to use strpos()
than to use strstr(). Most times users has problems to differentiate
the cases where the substring is found at position 0
and in the case where it is not found.
Example 2:
$needle = I love;
$haystack = I love PHP!;
//using strstr() - bad - exhaust of memory and cpu
if (strstr($haystack, $needle)){
// found
}
//using strpos() - good no exhaust of memory
if (strpos($haystack, $needle) === TRUE){
// found
}
-=-=-=-=-= End of example.
[2002-08-02 11:43:56] [EMAIL PROTECTED]
Feel free to write the part you would like to see, submit it to this
bug, and it will hopefully (probably) be added to the documentation.
[2002-08-02 09:00:23] [EMAIL PROTECTED]
Is it possible more information to be added to the docs of strstr()
that it is better to look if there is needle in a haystack by using
strpos() - in bold. Even small example.
Regards,
Andrey Hristov
--
Edit this bug report at http://bugs.php.net/?id=18705edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19959 [Opn-Csd]: fgets, fgetc
ID: 19959 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: win32/linux PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The meat of /php4/ext/standard/file.c::fgetc() hasn't changed since rev 1.1 It's just too simple not to be binary safe. Previous Comments: [2002-11-10 18:43:15] [EMAIL PROTECTED] The first post suggests fgetc() is binary safe, anyone know since when? Marking this as open until it's documented. [2002-10-19 17:57:51] [EMAIL PROTECTED] Is fgetc() binary safe now too? Only fgets() has been documented as such thus far. fgetc() lacks documention on the matter altogether. [2002-10-19 10:56:45] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. fgets() is now binary safe in latest CVS. [2002-10-18 12:22:24] [EMAIL PROTECTED] yes [2002-10-17 12:35:24] [EMAIL PROTECTED] I assume you have used 'rb' for mode in fopen..? 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/19959 -- Edit this bug report at http://bugs.php.net/?id=19959edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20663 [Opn]: trigger_error silently truncates the error to 1024 chars.
ID: 20663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.2.0
New Comment:
Helly-
Are you (or someone else) planning on committing that patch? I see
you wrote it against rev 1.193, but zend.c is up to 1.205 and the old
code (using ZEND_ERROR_BUFFER_SIZE) is still there. I'd like to put a
note on trigger_error()s doc page, but if it is indeed going to be
patched (with PHP 5.0)the note should also say that.
Although I just noticed you don't have karma for ZE2 either :)
Anyone else intending to apply this patch or something similar?
Previous Comments:
[2002-11-30 12:43:47] [EMAIL PROTECTED]
The following fix is against ZE2:
cvs -z3 -q diff zend.c (in directory S:\php4-HEAD\Zend)
Index: zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.193
diff -u -r1.193 zend.c
--- zend.c 30 Nov 2002 11:20:25 - 1.193
+++ zend.c 30 Nov 2002 16:55:20 -
@@ -703,8 +703,6 @@
}
-#define ZEND_ERROR_BUFFER_SIZE 1024
-
ZEND_API void zend_error(int type, const char *format, ...)
{
va_list args;
@@ -775,18 +773,7 @@
ALLOC_INIT_ZVAL(z_error_filename);
ALLOC_INIT_ZVAL(z_error_lineno);
ALLOC_INIT_ZVAL(z_context);
- z_error_message-value.str.val = (char *)
emalloc(ZEND_ERROR_BUFFER_SIZE);
-
-#ifdef HAVE_VSNPRINTF
- z_error_message-value.str.len =
vsnprintf(z_error_message-value.str.val, ZEND_ERROR_BUFFER_SIZE,
format, args);
- if (z_error_message-value.str.len ZEND_ERROR_BUFFER_SIZE-1)
{
- z_error_message-value.str.len =
ZEND_ERROR_BUFFER_SIZE-1;
- }
-#else
- strncpy(z_error_message-value.str.val, format,
ZEND_ERROR_BUFFER_SIZE);
- /* This is risky... */
- /* z_error_message-value.str.len =
vsprintf(z_error_message-value.str.val, format, args); */
-#endif
+ z_error_message-value.str.len =
vspprintf(z_error_message-value.str.val, 0, format, args);
z_error_message-type = IS_STRING;
z_error_type-value.lval = type;
[2002-11-26 17:36:19] [EMAIL PROTECTED]
trigger_error silently truncates your error after 1024 chars
(ZEND_ERROR_BUFFER_SIZE in the source). I didn't see this documented
anywhere, so I'm reporting it as a documentation problem. I'd rather
it be changed to take unlimited length strings than documented, but
documenting it would be a good first step.
--
Edit this bug report at http://bugs.php.net/?id=20663edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20663 [Opn-Csd]: trigger_error silently truncates the error to 1024 chars.
ID: 20663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Any
PHP Version: 4.2.0
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Actually there are some problems with that patch (re: Derick/Iliaa).
For the present time trigger_error will continue to only accept 1024
character messages. Documentation updated to reflect limit.
Previous Comments:
[2003-01-20 14:41:55] [EMAIL PROTECTED]
The attached patch is not valid, cause a) it doesn't work (it keeps
limiting at 1024 bytes) b) vspprintf is in PHP space, not Zend and c)
it might be a bad idea to have unlimited error lenghts because it might
be exploited in someway.
Derick
[2003-01-20 14:29:20] [EMAIL PROTECTED]
Helly-
Are you (or someone else) planning on committing that patch? I see
you wrote it against rev 1.193, but zend.c is up to 1.205 and the old
code (using ZEND_ERROR_BUFFER_SIZE) is still there. I'd like to put a
note on trigger_error()s doc page, but if it is indeed going to be
patched (with PHP 5.0)the note should also say that.
Although I just noticed you don't have karma for ZE2 either :)
Anyone else intending to apply this patch or something similar?
[2002-11-30 12:43:47] [EMAIL PROTECTED]
The following fix is against ZE2:
cvs -z3 -q diff zend.c (in directory S:\php4-HEAD\Zend)
Index: zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.193
diff -u -r1.193 zend.c
--- zend.c 30 Nov 2002 11:20:25 - 1.193
+++ zend.c 30 Nov 2002 16:55:20 -
@@ -703,8 +703,6 @@
}
-#define ZEND_ERROR_BUFFER_SIZE 1024
-
ZEND_API void zend_error(int type, const char *format, ...)
{
va_list args;
@@ -775,18 +773,7 @@
ALLOC_INIT_ZVAL(z_error_filename);
ALLOC_INIT_ZVAL(z_error_lineno);
ALLOC_INIT_ZVAL(z_context);
- z_error_message-value.str.val = (char *)
emalloc(ZEND_ERROR_BUFFER_SIZE);
-
-#ifdef HAVE_VSNPRINTF
- z_error_message-value.str.len =
vsnprintf(z_error_message-value.str.val, ZEND_ERROR_BUFFER_SIZE,
format, args);
- if (z_error_message-value.str.len ZEND_ERROR_BUFFER_SIZE-1)
{
- z_error_message-value.str.len =
ZEND_ERROR_BUFFER_SIZE-1;
- }
-#else
- strncpy(z_error_message-value.str.val, format,
ZEND_ERROR_BUFFER_SIZE);
- /* This is risky... */
- /* z_error_message-value.str.len =
vsprintf(z_error_message-value.str.val, format, args); */
-#endif
+ z_error_message-value.str.len =
vspprintf(z_error_message-value.str.val, 0, format, args);
z_error_message-type = IS_STRING;
z_error_type-value.lval = type;
[2002-11-26 17:36:19] [EMAIL PROTECTED]
trigger_error silently truncates your error after 1024 chars
(ZEND_ERROR_BUFFER_SIZE in the source). I didn't see this documented
anywhere, so I'm reporting it as a documentation problem. I'd rather
it be changed to take unlimited length strings than documented, but
documenting it would be a good first step.
--
Edit this bug report at http://bugs.php.net/?id=20663edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18816 [Opn-Csd]: results of ip2long and crc32 differ on different os/architectures
ID: 18816
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux, Tru64
PHP Version: 4CVS-2002-08-08
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-08-10 06:59:59] [EMAIL PROTECTED]
All functions that requrie unsigned int may be affected.
BTW, PostgreSQL OID is free from this restriction, since I changed
source to use string if value is larger than 2^31. So postgreSQL
document can be left as is.
[2002-08-08 17:01:31] [EMAIL PROTECTED]
Reopened this. This should definitly be documented! On ip2long
documentation it is, on crc32 it is not. Which other functions are
affected by this?
[2002-08-08 16:23:55] [EMAIL PROTECTED]
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
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
This is because you are using 2 different architectures, on X86 (AMD
k6) ints are 32 bit, but on Compaq Tru64 (ALpha EV68) they are 64 bit.
Since PHP uses signed ints you got a negative number on X86 where
signed ints are limited to 2147483647 and your result is 3 billion.
If you explicitly tell PHP to output an unsigned number it will work
correctly.
printf(%u, ip2long('192.168.0.1'));
-
3232235521
Same logic applies to your crc, example.
[2002-08-08 16:09:58] [EMAIL PROTECTED]
Ahh... Please note that I may not be reachable in the next days for
questions, but you may use http://www.testdrive.compaq.com/ to verify
this
[2002-08-08 16:08:45] [EMAIL PROTECTED]
Following Script produces this output:
$ip = 192.168.0.1;
echo($ip\n);
echo(ip2long($ip));
On Debian/i386 (AMD K6):
192.168.0.1
-1062731775
On Compaq Tru64 (ALpha EV68):
192.168.0.1
3232235521
===
Following Script produces this output:
$text = Der schnelle braune Fuchs springt über den blöden Hund.;
echo $text\n;
echo(crc32($text));
On Debian/i386 (AMD K6):
Der schnelle braune Fuchs springt über den blöden Hund.
-2050320634
On Compaq Tru64 (Alpha EV68):
Der schnelle braune Fuchs springt über den blöden Hund.
1367081892
--
Edit this bug report at http://bugs.php.net/?id=18816edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21502 [Fbk-Csd]: Spanish translation
ID: 21502 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. es/chapters/intro.xml I took care of it. Previous Comments: [2003-01-07 23:18:13] [EMAIL PROTECTED] What manual page is this from? Also, would you like to join the spanish translation team? :) [2003-01-07 19:36:44] [EMAIL PROTECTED] Hi, there is a problem with a word in spanish that is not correct. Parser is analizador in spanish, so in the part named ¿Qué se puede hacer con PHP? You have: *Scripts en la parte del servidor. Este es el campo más tradicional y el principal campo de trabajo. Se necesitan tres cosas para que esto funcione. El parseador PHP (CGI ó módulo), un servidor web y un navegador. You should have: Scripts en la parte del servidor. Este es el campo más tradicional y el principal campo de trabajo. Se necesitan tres cosas para que esto funcione. El analizador PHP ^^ -- Edit this bug report at http://bugs.php.net/?id=21502edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21325 [Opn-Csd]: Spelling Error in Online Docs
ID: 21325 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.3.0 Assigned To: pollita New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Appreciated! Previous Comments: [2003-01-01 21:58:58] [EMAIL PROTECTED] On page http://www.php.net/manual/en/function.mail.php this text appears: Note: You must use \r\n to seperate headers, although some Unix mail transfer agents may work with just a single newline (\n). Separate is mis-spelled as seperate. -- Edit this bug report at http://bugs.php.net/?id=21325edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14298 [Asn-Csd]: PUT method not supported in PHP 4
ID: 14298
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type:Documentation problem
PHP Version: 4.0.6
Assigned To: hholzgra
Previous Comments:
[2002-12-01 23:58:32] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Provided example of using php://stdin and note re: change from PHP3.
[2002-11-12 07:41:26] [EMAIL PROTECTED]
this is a PHP 3 only feature
that noone ever ported to PHP 4 ...
with 4.3 you will be able to read
the PUT data from the php://input stream
as the $PHP_PUT stuff in PHP 3 seems to
be something almost never used and as
the new streams solution is so easy to
use i think it is not worth to port the
PHP 3 feature here ...
in 4.3 you will be able to just do a
$in = fopen(php://input,rb);
$out = fopen($outfile,wb);
while(!feof($in)) {
fwrite($out, fread($in, $bufsize));
}
fclose($in);
fclose($out);
no nead to deal with temporary files,
no disk space wasted when the script
doesn't need the PUT data, and the
approach is not limited to PUT requests
but will work with all HTTP methods
carrying content
changed to documentation problem
[2002-05-13 08:27:02] [EMAIL PROTECTED]
Just wanted to drop a note about a test I've done:
I tried a simple perl script getting the PUT file and it worked.
Calling the same script through PHP yields no file meaning that PHP
does something the uploaded file since the perlscript used by itself
works and then called through PHP does'nt.
[2002-05-09 07:55:50] [EMAIL PROTECTED]
If you find the temporary file variable I would be much obliged if you
could drop me a line.
BTW I was thinking would'nt it be better to have the PUT values in the
superglobal $_FILES ? Or at least in a $HTTP_PUT_FILE var.
A possible solution could be something like the following:
$HTTP_PUT_FILE['request_uri']
Path of the proposed upload like /mytest/filename.htm
$HTTP_PUT_FILE['path_translated']
The full path of the proposed upload like
/usr/home/foo/bar/public_html/mytest/filename.htm
$HTTP_PUT_FILE['size']
The size, in bytes, of the uploaded file.
$HTTP_PUT_FILE['tmp_name']
Temp name something like /tmp/hfdhjfufd8733
My only bad is that I cant program in C otherwise I would have been
there doing it already.
[2002-05-08 09:44:42] [EMAIL PROTECTED]
Current status on this is that I ignored it for a while -
I am taking a look at it again.
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/14298
--
Edit this bug report at http://bugs.php.net/?id=14298edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14298 [Csd-Opn]: PUT method not supported in PHP 4
ID: 14298
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type:Documentation problem
PHP Version: 4.0.6
Assigned To: hholzgra
Previous Comments:
[2002-12-01 23:58:32] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Provided example of using php://stdin and note re: change from PHP3.
[2002-11-12 07:41:26] [EMAIL PROTECTED]
this is a PHP 3 only feature
that noone ever ported to PHP 4 ...
with 4.3 you will be able to read
the PUT data from the php://input stream
as the $PHP_PUT stuff in PHP 3 seems to
be something almost never used and as
the new streams solution is so easy to
use i think it is not worth to port the
PHP 3 feature here ...
in 4.3 you will be able to just do a
$in = fopen(php://input,rb);
$out = fopen($outfile,wb);
while(!feof($in)) {
fwrite($out, fread($in, $bufsize));
}
fclose($in);
fclose($out);
no nead to deal with temporary files,
no disk space wasted when the script
doesn't need the PUT data, and the
approach is not limited to PUT requests
but will work with all HTTP methods
carrying content
changed to documentation problem
[2002-05-13 08:27:02] [EMAIL PROTECTED]
Just wanted to drop a note about a test I've done:
I tried a simple perl script getting the PUT file and it worked.
Calling the same script through PHP yields no file meaning that PHP
does something the uploaded file since the perlscript used by itself
works and then called through PHP does'nt.
[2002-05-09 07:55:50] [EMAIL PROTECTED]
If you find the temporary file variable I would be much obliged if you
could drop me a line.
BTW I was thinking would'nt it be better to have the PUT values in the
superglobal $_FILES ? Or at least in a $HTTP_PUT_FILE var.
A possible solution could be something like the following:
$HTTP_PUT_FILE['request_uri']
Path of the proposed upload like /mytest/filename.htm
$HTTP_PUT_FILE['path_translated']
The full path of the proposed upload like
/usr/home/foo/bar/public_html/mytest/filename.htm
$HTTP_PUT_FILE['size']
The size, in bytes, of the uploaded file.
$HTTP_PUT_FILE['tmp_name']
Temp name something like /tmp/hfdhjfufd8733
My only bad is that I cant program in C otherwise I would have been
there doing it already.
[2002-05-08 09:44:42] [EMAIL PROTECTED]
Current status on this is that I ignored it for a while -
I am taking a look at it again.
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/14298
--
Edit this bug report at http://bugs.php.net/?id=14298edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20843 [Opn]: Alt text in documentation pages hamper accessibility
ID: 20843 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type:Website problem +Bug Type:Documentation problem PHP Version: 4.2.3 New Comment: Agreed, this violates accessability standards. Reclassified as a documentation problem as change needs to be made in the phpweb build process. Previous Comments: [2002-12-05 16:55:18] [EMAIL PROTECTED] On documentation pages such as http://www.php.net/manual/en/funcref.php in the left column the sections are listed and have a graphical bullet point in front of them. These graphical bullet points have the section name as the alt text. When browsing without images all this does is make each section title appear twice (once as the image alt text and once as the actual text that follows it) and it looks very wierd. A better alt text would be the middot entity or nothing at all. For reference I noticed this when trying to access the page in small screen rendering mode as provided in Opera 7 for Windows beta which mimics how pages look on the version of Opera for small screen devices (ie mobile phones) they make. -- Edit this bug report at http://bugs.php.net/?id=20843edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20743 [Opn-Asn]: mysql_error in mysql code examples
ID: 20743 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Documentation problem Operating System: Linux PHP Version: 4.2.3 -Assigned To: +Assigned To: pollita Previous Comments: [2002-12-01 03:04:11] [EMAIL PROTECTED] Hello, I answer questions on a php help bbs (www.phpworld.com). One of the most common problems reported is that the users don't know why their database calls are not working. Usually they have copied the code right out of the examples (e.g. mysql_connect()), which do not utilize mysql_error(). I was wondering if these examples could be changed to use mysql_error() and thus reduce newbie confusion. Thank you for your time. -- Edit this bug report at http://bugs.php.net/?id=20743edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20743 [Asn-Csd]: mysql_error in mysql code examples
ID: 20743 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.2.3 Assigned To: pollita New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-01 03:04:11] [EMAIL PROTECTED] Hello, I answer questions on a php help bbs (www.phpworld.com). One of the most common problems reported is that the users don't know why their database calls are not working. Usually they have copied the code right out of the examples (e.g. mysql_connect()), which do not utilize mysql_error(). I was wondering if these examples could be changed to use mysql_error() and thus reduce newbie confusion. Thank you for your time. -- Edit this bug report at http://bugs.php.net/?id=20743edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #14298 [Ana-Csd]: PUT method not supported in PHP 4
ID: 14298
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type:Documentation problem
PHP Version: 4.0.6
Assigned To: hholzgra
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Provided example of using php://stdin and note re: change from PHP3.
Previous Comments:
[2002-11-12 07:41:26] [EMAIL PROTECTED]
this is a PHP 3 only feature
that noone ever ported to PHP 4 ...
with 4.3 you will be able to read
the PUT data from the php://input stream
as the $PHP_PUT stuff in PHP 3 seems to
be something almost never used and as
the new streams solution is so easy to
use i think it is not worth to port the
PHP 3 feature here ...
in 4.3 you will be able to just do a
$in = fopen(php://input,rb);
$out = fopen($outfile,wb);
while(!feof($in)) {
fwrite($out, fread($in, $bufsize));
}
fclose($in);
fclose($out);
no nead to deal with temporary files,
no disk space wasted when the script
doesn't need the PUT data, and the
approach is not limited to PUT requests
but will work with all HTTP methods
carrying content
changed to documentation problem
[2002-05-13 08:27:02] [EMAIL PROTECTED]
Just wanted to drop a note about a test I've done:
I tried a simple perl script getting the PUT file and it worked.
Calling the same script through PHP yields no file meaning that PHP
does something the uploaded file since the perlscript used by itself
works and then called through PHP does'nt.
[2002-05-09 07:55:50] [EMAIL PROTECTED]
If you find the temporary file variable I would be much obliged if you
could drop me a line.
BTW I was thinking would'nt it be better to have the PUT values in the
superglobal $_FILES ? Or at least in a $HTTP_PUT_FILE var.
A possible solution could be something like the following:
$HTTP_PUT_FILE['request_uri']
Path of the proposed upload like /mytest/filename.htm
$HTTP_PUT_FILE['path_translated']
The full path of the proposed upload like
/usr/home/foo/bar/public_html/mytest/filename.htm
$HTTP_PUT_FILE['size']
The size, in bytes, of the uploaded file.
$HTTP_PUT_FILE['tmp_name']
Temp name something like /tmp/hfdhjfufd8733
My only bad is that I cant program in C otherwise I would have been
there doing it already.
[2002-05-08 09:44:42] [EMAIL PROTECTED]
Current status on this is that I ignored it for a while -
I am taking a look at it again.
[2002-05-03 12:15:39] [EMAIL PROTECTED]
Whats happening on this subject?
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/14298
--
Edit this bug report at http://bugs.php.net/?id=14298edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #2965 [Opn-Csd]: The = operator does not work properly on characters.
ID: 2965 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Redhat Linux 6.0 PHP Version: 4 Assigned To: hholzgra New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. PHP follows Perl convention when performing arithmetic operations on character values. Explanation added in PHP-DOCs Previous Comments: [2002-09-30 19:48:47] [EMAIL PROTECTED] changed to documentation problem and reopened until verified [2002-09-30 16:49:59] [EMAIL PROTECTED] it may look strange but it is intended behaviour [1999-12-13 10:09:12] [EMAIL PROTECTED] for($i = 'A'; $i = 'Z' ; $i++) echo $ibr\n; -- Edit this bug report at http://bugs.php.net/?id=2965edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #8353 [Opn-Csd]: foreach modify array pointer
ID: 8353
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type:Documentation problem
PHP Version: 4.4.0-dev
Assigned To: philip
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Modified Note re: Works on a Copy
Previous Comments:
[2002-11-28 11:42:45] [EMAIL PROTECTED]
The foreach() page will be updated and made more clear on this
behavior. Regarding the pointer, foreach() indeed behaves like
while/each() (except for the initial reset) and moves the pointer past
the end. So although it provides a copy to work with it still affects
the original arrays pointer!
[2002-11-27 10:32:33] [EMAIL PROTECTED]
As I've been taught, foreach doesn't affect the pointer as it merely
works on a copy. Also, the following note exists in the foreach()
entry of the manual and has for over two years:
Note: Also note that foreach operates on a copy of the specified
array, not the array itself, therefore the array pointer is not
modified as with the each() construct and changes to the array element
returned are not reflected in the original array.
That was added by Sterling here:
http://cvs.php.net/diff.php/phpdoc/en/language/control-structures.xml?login=2r1=1.9r2=1.10ty=h
Everyone assumes foreach works on a copy and only a copy. IMHO each()
isn't a fair comparison because it doesn't work on a copy.
[2002-11-24 23:10:40] [EMAIL PROTECTED]
IMO this is not a bug. Foreach works virtually like while + each
combination, with a few exceptions such as not requiring a reset()
prior to execution since it does not care about the current position in
the array.
As far as current(), next() and simular are concerned,
while (each($arr)); == foreach ($arr as $v);, once the loops are
complete current() will return FALSE. This IMO is a consistent
behaviour and is definately not a bug. I believe this is merely a
documentation issue.
[2002-11-21 15:21:34] [EMAIL PROTECTED]
foreach essentially REMOVES the array pointer alltogether on the
original array.
$arr = array('a','b'); foreach ($arr as $v); var_dump( current($arr)
);
$arr = array('a','b'); foreach ($arr as $v); reset($arr); var_dump(
current($arr) );
Results:
bool(false)
string(1) a
Using key() instead of current() results in NULL instead of false.
Where did the pointer go?
Conclusion:
Either foreach() has a feature that removes the array pointer from the
original array or it's a bug. If it's seen as a feature please explain
why so it can be documented.
[2001-03-09 21:32:57] [EMAIL PROTECTED]
no feedback.
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/8353
--
Edit this bug report at http://bugs.php.net/?id=8353edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20622 [Opn-Csd]: auto_prepend_file 'reset'
ID: 20622 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Any PHP Version: 4.4.0-dev New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Note added to explain the use of none Previous Comments: [2002-11-26 17:16:17] [EMAIL PROTECTED] goba: because it was documented :) But you're right, it needs change. philip: looking at the source, this only applies to apache sapi's and goes for any php_value. It is not special for auto_prepend_file. (See sapi/apache/mod_php4.c line 683). Additionally - the special value 'none' is marked as systemitem of class constant in en/chapters/config.xml of the documentation. This isn't reflected in the HTML representation in any way. [2002-11-26 14:27:07] [EMAIL PROTECTED] Here's some related information. In php.ini-dist: ; Automatically add files before or after any PHP document. auto_prepend_file = auto_append_file = Which means the default value is essentially as the docs say in the defaults table. Also the docs mention the special none value but could someone explain the difference a bit? So when setting outside of php.ini one must use none instead of ? Does none make sense in php.ini too? [2002-11-26 13:28:13] [EMAIL PROTECTED] If you propose a change, why mark it bogus??? [2002-11-26 07:37:25] [EMAIL PROTECTED] 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 Actually - looking further it's documented under the configuration directives. (maybe the table 4-5 Data handling Configuration Options could list 'none' instead of ). [2002-11-26 07:32:56] [EMAIL PROTECTED] Yep. Not document ( http://www.php.net/manual/en/configuration.changes.php ) - recategorizing. 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/20622 -- Edit this bug report at http://bugs.php.net/?id=20622edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17389 [Opn-Csd]: max_upload_filesize setting format is problematic
ID: 17389 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Also including comments re: boolean values. Previous Comments: [2002-09-30 20:18:38] [EMAIL PROTECTED] reclassified [2002-05-23 10:07:41] [EMAIL PROTECTED] The documentation states that max_upload_filesize is an integer, although the result from ini_get is 2M. This is problematic for the following reasons: 1. With the documentation stating the format as an integer, code can be written to output BAD code such as: $my_value = 2M; I fell into this trap and didn't locate the problem easily because my test installations (unfortunately) stated the max_upload_filesize as a true integer inside php.ini. 2. It is not clear how PHP handles the output of GOOD code like: $my_value = 2M; If I later have code like: if ($my_value $this_value) // i.e., if (2M 345) Will it break? Will 2M be considered an integer and converted automatically to 2097152? If this is the case then it is not immediately evident inside of the documentation. -- Edit this bug report at http://bugs.php.net/?id=17389edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #13568 [Opn-Csd]: PHP3 semantics have been retained for nested functions
ID: 13568
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: *
PHP Version: 4.10
New Comment:
Documentation at http://www.php.net/manual/en/functions.php updted.
Why conditional functions don't immediately exist.
Previous Comments:
[2002-09-09 08:14:10] [EMAIL PROTECTED]
the new semantics that allows calling functions prior to their
definition only works for functions defined in a global scope
as soon as a function definition is within a conditional
block or nested within another function the new function
cannot be created at parse time as it is not known yet
wether the condition will be met or the surrounding
function ever called, so these functions are created at
runtime instead when execution reaches this part of the code
so it is rather obvious that you can't call such a function ahead of
it's definition
well, maybe not *that* obvious, reclassified as documentation problem
...
[2001-12-14 14:01:10] [EMAIL PROTECTED]
Parhaps, ZE2 should depreciate this syntax.
I really want BNF for PHP.
[2001-10-05 14:56:31] [EMAIL PROTECTED]
container ();
a script to reproduce the error quickly.
function container () {
function nested_php3 () {
echo this will be output;
}
nested_php3 ();
nested_php4 ();
function nested_php4 () {
echo this won't be output;
}
}
--
Edit this bug report at http://bugs.php.net/?id=13568edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] [PATCH] /en/reference/math/functions/log.xml
The attached patch updates rev 1.3 of /en/reference/math/functions/log.xml to include documentation for new functionality added to log() in rev. 1.94 of /ext/standard/math.c in /php4 --- log.xml Sun Nov 10 22:13:50 2002 +++ log-smg.xml Sun Nov 10 22:36:59 2002 -11,10 +11,20 methodsynopsis typefloat/typemethodnamelog/methodname methodparamtypefloat/typeparameterarg/parameter/methodparam + methodparam +choice=opttypefloat/typeparameterbase/parameter/methodparam /methodsynopsis para - Returns the natural logarithm of parameterarg/parameter. + If parameterbase/parameter is specified, log() returns + logsubscripparameterbase/parameter/subscrip + parameterarg/parameter, otherwise log() returns + the natural logarithm of parameterarg/parameter. /para +note + para + The parameterbase/parameter parameter became available + with PHP ver 4.3.0 + /para +/note /refsect1 /refentry -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
