[PHP-DOC] #25464 [Csd]: SID always defined or not documention bug?
ID: 25464 User updated by: jc at mega-bucks dot co dot jp Reported By: jc at mega-bucks dot co dot jp Status: Closed Bug Type: Documentation problem Operating System: Linux PHP Version: 4.3.3 New Comment: Great! Thanks for looking into this. Previous Comments: [2003-09-10 00:15:23] [EMAIL PROTECTED] This is actually fixed already in CVS..the manual just hasn't been generated since that. Patience. :) [2003-09-10 00:08:08] [EMAIL PROTECTED] SID is always defined. Someone should fix that one manual page. :) The constant 'SID' is defined to '' if the session id is set in a cookie for the request. ---- [2003-09-09 23:22:47] jc at mega-bucks dot co dot jp Description: These two documentation pages have conflicting views on wether SID is always defined or not. The first one says it only defined is the right cookie wasn't sent and the other says it is always defined. Which one is it :) http://jp2.php.net/session_id Note that SID is only defined if the client didn't send the right cookie. See also Session handling. http://jp2.php.net/manual/en/ref.session.php Alternatively, you can use the constant SID which is always defined. -- Edit this bug report at http://bugs.php.net/?id=25464&edit=1
[PHP-DOC] #25464 [NEW]: SID always defined or not documention bug?
From: jc at mega-bucks dot co dot jp Operating system: Linux PHP version: 4.3.3 PHP Bug Type: Documentation problem Bug description: SID always defined or not documention bug? Description: These two documentation pages have conflicting views on wether SID is always defined or not. The first one says it only defined is the right cookie wasn't sent and the other says it is always defined. Which one is it :) http://jp2.php.net/session_id Note that SID is only defined if the client didn't send the right cookie. See also Session handling. http://jp2.php.net/manual/en/ref.session.php Alternatively, you can use the constant SID which is always defined. -- Edit bug report at http://bugs.php.net/?id=25464&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25464&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25464&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25464&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25464&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25464&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25464&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25464&r=support Expected behavior: http://bugs.php.net/fix.php?id=25464&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25464&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25464&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25464&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25464&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25464&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25464&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25464&r=gnused
[PHP-DOC] #24642 [NEW]: pg_field_is_null first row is 0 not 1
From: jc at mega-bucks dot co dot jp Operating system: Linux PHP version: 4.3.3RC1 PHP Bug Type: Documentation problem Bug description: pg_field_is_null first row is 0 not 1 Description: For the function pg_field_is_null() row and column indexing seem to start at 0. Could you add that to the function7s description. It was not immediately obvious to me that row counting would start at 0 ... -- Edit bug report at http://bugs.php.net/?id=24642&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24642&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24642&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24642&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24642&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24642&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24642&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24642&r=support Expected behavior: http://bugs.php.net/fix.php?id=24642&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24642&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24642&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24642&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24642&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24642&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24642&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24642&r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21318 [Csd->Opn]: str_pad will pad even if input_len + pad_str_len > pad_length
ID: 21318
User updated by: jc at mega-bucks dot co dot jp
Reported By: jc at mega-bucks dot co dot jp
-Status: Closed
+Status: Open
Bug Type: Documentation problem
-Operating System: Red Hat Linux 7.2
+Operating System: Linux
PHP Version: 4.3.0
Assigned To: hholzgra
New Comment:
Could you state *how* the bug was fixed? i.e. was the behaviour of the
function changed or was the documentation changed to explain the
current behaviour?
Thanks!
Previous Comments:
[2003-07-04 17:08:15] [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.
[2003-01-01 05:35:33] jc at mega-bucks dot co dot jp
str_pad pad the input string even when the length of the pad string
cannot be evenly dived into the length of the input stirng +
pad_length.
This is not necessarily a bug but the behaviour should be documented.
I.e. in some cases the user might want the string be padded only with
*full-length* pad strings, and not truncated pad strings.
The following code illustrates:
echo str_pad("1", 2, "AB");
OUPUT:
1A
The output could be viewed as "incorrect" since pad_str was aksed to
pad with "AB", not to pad with "A".
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=21318&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #18747 [Com]: pg_result_error is complete useless
ID: 18747 Comment by: jc at mega-bucks dot co dot jp Reported By: vincent at sunlight dot tmfweb dot nl Status: Assigned Bug Type: Documentation problem Operating System: Linux PHP Version: 4.2.2 Assigned To: yohgaki New Comment: When will the documentation be updated? This bug report has been open for 10 months now ... The documentation clearly states that we should be using this function instead of the *old* pg_last_error(): http://jp.php.net/manual/en/function.pg-last-error.php Use pg_result_error(), pg_result_status() and pg_connection_status() for better error handling. But as the first person who reported this bug noted, the current implementation of this function is useless. You can't pass it a valid ressource identifier because pg_query() returns false on failure. Having a valid bug report open for almost one year is a bit too long I really want to use this function as it seems very useful and more robust than pg_last_error() but I can't figure out at all how to use it ... Previous Comments: [2002-08-07 03:12:12] [EMAIL PROTECTED] Looks like I need to explain how it could be useful. If you cannot wait, read libpq manual. [2002-08-05 17:58:17] vincent at sunlight dot tmfweb dot nl The function pg_result_error() supposedly gives the error message for some failed SQL query after calling pg_query() with that query. It must be given a resource identifier of the result to get the error message for that result (sounds alright). However, function pg_query() returns FALSE if a query failed instead of a result identifier, so what can possibly be passed to pq_result_error() in this case? The query certainly went wrong, but there's no way to check exactly what, as there is no resource identifier... Almost looks like a Catch 22. -- Edit this bug report at http://bugs.php.net/?id=18747&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23195 [Csd]: copying an array resets its pointer
ID: 23195 User updated by: jc at mega-bucks dot co dot jp Reported By: jc at mega-bucks dot co dot jp Status: Closed Bug Type: Documentation problem -Operating System: Red Hat Linux 8.0 +Operating System: all -PHP Version: 4.3.2RC1 +PHP Version: 4.3.0 Assigned To: philip New Comment: Thank you! Can't wait to read the new section on array pointers. I had no idea that PHP's array were so sensitive to manipulation ;) Previous Comments: [2003-06-21 22:14:19] [EMAIL PROTECTED] This behavior has been documented and will show up when the manual is next built, thanks for the report :) http://cvs.php.net/cvs.php/phpdoc/en/reference/array/functions/each.xml Also, added "explanation of pointers" to the TODO as currently no section in the manual clearly explains the topic of array pointers. [2003-06-10 02:17:11] [EMAIL PROTECTED] pong [2003-06-10 02:05:00] jc at mega-bucks dot co dot jp Fine, it's a lack of documentation about some weird PHP behaviour :) (yes it *is* weird) Somebody please fix it. This bug keeps geeting closed and reopened and passed around. End the torment ^_~ [2003-06-10 01:58:52] [EMAIL PROTECTED] This isn't a bug in anything but docs.. [2003-06-10 00:53:04] [EMAIL PROTECTED] This makes no sense to me, why would assigning an array to another variable affect the original arrays pointer? Even the array it's assigned to keeps the original pointer: Either $array should also keep its pointer or $array2 should also have a reset pointer. I'd assume both would keep the current pointer, or maybe just $array2 would have a reset pointer :). Current behavior is certainly not documented, and are you guys sure this isn't a bug? 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/23195 -- Edit this bug report at http://bugs.php.net/?id=23195&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19252 [Csd]: function only accepts scalars or constants as default values
ID: 19252
User updated by: jc at mega-bucks dot co dot jp
Reported By: jc at mega-bucks dot co dot jp
Status: Closed
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
Thanks! Keep up the good work. God knows *I* hate documentting my code
so I highly appreciate the work that goes in to PHP's documentation!
Previous Comments:
[2003-06-19 06:06:50] [EMAIL PROTECTED]
Just incorporated your suggestion into the manual.
Next time the manual is build, the changes will show up on the
website.
Thanks for your report
[2003-06-17 04:35:20] jc at mega-bucks dot co dot jp
I agree that is *is* documented, even if a bit hidden. I am happy if
the documentation is left as is or changed to this:
"The default value must be a constant expression, not (for example) a
variable, class member, or function call .
Thanks.
[2003-06-17 04:27:59] [EMAIL PROTECTED]
It seems this is documented at:
http://www.php.net/manual/en/functions.arguments.php#functions.arguments.default
Maybe a bit hidden
[2003-01-31 13:04:32] [EMAIL PROTECTED]
Yeah, we may as well mention this here:
file:phpdoc/{lang}/language/functions.xml
section:
[2002-09-26 19:56:13] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
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/19252
--
Edit this bug report at http://bugs.php.net/?id=19252&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #19252 [Opn]: function only accepts scalars or constants as default values
ID: 19252
User updated by: jc at mega-bucks dot co dot jp
Reported By: jc at mega-bucks dot co dot jp
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
I agree that is *is* documented, even if a bit hidden. I am happy if
the documentation is left as is or changed to this:
"The default value must be a constant expression, not (for example) a
variable, class member, or function call .
Thanks.
Previous Comments:
[2003-06-17 04:27:59] [EMAIL PROTECTED]
It seems this is documented at:
http://www.php.net/manual/en/functions.arguments.php#functions.arguments.default
Maybe a bit hidden
[2003-01-31 13:04:32] [EMAIL PROTECTED]
Yeah, we may as well mention this here:
file:phpdoc/{lang}/language/functions.xml
section:
[2002-09-26 19:56:13] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-09-05 15:22:54] [EMAIL PROTECTED]
No it wouldn't be nice to do #2, thats just not fun programming
practice/maintaince.
Can you give a URL to the section of the documentation you're asking to
be updated?
----
[2002-09-05 11:09:23] jc at mega-bucks dot co dot jp
Could you add to the docs in the section on functions and default
argument values that default values can only be scalers or constants?
these won't work:
1- function a ($b = $val) {}
2- function b ($a = another_function()) {}
This link offers some workarounds, eventhough it would be really nice
to be able to do #2, don't you think ;)
http://marc.theaimsgroup.com/?l=php-general&m=91877248424055&;
--
Edit this bug report at http://bugs.php.net/?id=19252&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23195 [Opn]: copying an array resets its pointer
ID: 23195
User updated by: jc at mega-bucks dot co dot jp
Reported By: jc at mega-bucks dot co dot jp
Status: Open
Bug Type: Documentation problem
Operating System: Red Hat Linux 8.0
PHP Version: 4.3.2RC1
New Comment:
Fine, it's a lack of documentation about some weird PHP behaviour :)
(yes it *is* weird)
Somebody please fix it. This bug keeps geeting closed and reopened and
passed around. End the torment ^_~
Previous Comments:
[2003-06-10 01:58:52] [EMAIL PROTECTED]
This isn't a bug in anything but docs..
[2003-06-10 00:53:04] [EMAIL PROTECTED]
This makes no sense to me, why would assigning an array to another
variable affect the original arrays pointer? Even the array it's
assigned to keeps the original pointer:
Either $array should also keep its pointer or $array2 should also have
a reset pointer. I'd assume both would keep the current pointer, or
maybe just $array2 would have a reset pointer :). Current behavior is
certainly not documented, and are you guys sure this isn't a bug?
----
[2003-04-25 00:10:48] jc at mega-bucks dot co dot jp
Thanks for looking into this, but I cannot find anywhere in the
documenation that states that assigning an array to a variable resets
the array's pointer to the first element. Can you point me to such
documentation?
Furthermore if you are right, and I'm sure you are, then some of the
documentation is wrong or confusing at best. Consider the following
from the docs:
http://www.php.net/manual/en/control-structures.foreach.php
The following are also functionally identical:
reset ($arr);
while (list($key, $value) = each ($arr)) {
echo "Key: $key; Value: $value\n";
}
foreach ($arr as $key => $value) {
echo "Key: $key; Value: $value\n";
}
But has you said, those are *not* functionally identical.
Or from http://www.php.net/manual/en/function.each.php
each() is typically used in conjunction with list() to traverse an
array; for instance, $_POST:
Example 2. Traversing $_POST with each()
echo "Values submitted via POST method:\n";
reset ($_POST);
while (list ($key, $val) = each ($_POST)) {
echo "$key => $val\n";
}
Reading the documentation on each() and on arrays the above two
examples teach that using a while(list() = each()) is a correct way of
traversing an array. Which it obviously is *not* if you plan on
assigning the array you are traversing to a variable ...
Either the each() function should be removed to force the use of the
assignment-safe 'foreach()' or the documentation should mention that
when assigning an array to a variable the current element-pointer is
reset.
[2003-04-24 19:49:05] [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
When you assign the array to another variable the internal array
position pointer gets reset. Which causes you loop which depends on the
array position to loop indefinately.
Use foreach() or a for() loop.
[2003-04-18 21:19:43] [EMAIL PROTECTED]
Here is a shorter example that demonstrates the 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/23195
--
Edit this bug report at http://bugs.php.net/?id=23195&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #23826 [Csd->Opn]: ob_end_clean() returns error notice when buffer is empty
ID: 23826 User updated by: jc at mega-bucks dot co dot jp Reported By: jc at mega-bucks dot co dot jp -Status: Closed +Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 8.0 PHP Version: 4.3.2RC4 Assigned To: helly New Comment: helly: even if it is decided that the notice is valid, the documentation still needs to be updated to state this. Previous Comments: [2003-05-27 18:48:48] jc at mega-bucks dot co dot jp I totally understand your point of view. It's just that in my opinion if an E_NOTICE is generated then it probably means there is something wrong with my code [1]. If there is nothing wrong with calling ob_end_clean() on an empty buffer, then why have it generate a notice? Using @ would get rid of the notice, but if I understand the documentation correctly for the use of @ then I won't catch any *real* errors messages, they'll just be ignored [2]. So basically my question/problem comes down to this. Why is ob_end_clean() generating a notice? It's generating a notice to tell you that you call the function on an empty output buffer. Why is it bothering telling me this? It's bothering to tell me because either a) this is wrong and I shouldn't be doing it or b) it's being friendly and thinks it should let me know that I did something that I probably didn't intend to do. So is it case A (an error) or case B (possible poor programming). If it's case A then an ERROR should be generated, not a notice. If it's case B then #1- I can understand the logic being a notice for an uninitialized variable, but the output buffer is something generated by PHP in the backgroud, so it's not like I am trying to use something I didn't initialize ... #2- there should be a way for me to prevent the generation of "possible sloppy programming" friendly notices by checking beforehand that the buffer is not empty if it is deemed that this friendly notice is valid. And the prevention of these notices shold not interfere with the generation of *real* ERROR messages ... Just my 2 cents ;) [1] http://jp.php.net/manual/en/language.operators.errorcontrol.php Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why. [2] http://jp.php.net/manual/en/ref.errorfunc.php NOTICE messages will warn you about possibls bugs in your code. [...] Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. [2003-05-27 13:25:16] [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 1) It is a notice and not an error 2) this notice tells you: you are doing unnecessary stuff 3) to clear all buffers do: while(@ob_end_clean()); [2003-05-27 10:12:58] [EMAIL PROTECTED] Why do you want to check before calling ob_end_clean()? It seems you simply want to call that then why not @ob_end_clean()? ------------------------ [2003-05-27 03:19:41] jc at mega-bucks dot co dot jp Ok. I understand the "bug fix" but that fix now causes another problem ... I have a custom error handler with the following code: $buffer = ob_get_contents(); ob_end_clean(); The call to ob_end_clean() will throw a notice if the buffer if empty, which will cause the error handler to either fail or call itself again (possibly infinitely?). So just to be clear, it seems you are saying that *technically* calling ob_end_clean() on an empty buffer is incorrect? If this is so, what is the proprer way of checking if the buffer is empty before calling ob_end_clean()? If there is a way of checking wether the buffer is empty or not then all is fine, if not then there is a problem ;) [2003-05-27 03:10:02] [EMAIL PROTECTED] You don't need to submit anymore bug reports.. And I meant with that crash preventing that it now throws an error and returns false, reviously when it didn't check the buffer, it just crashed. (that was the fix) The remainder of the comments for this report
[PHP-DOC] #23826 [Csd]: ob_end_clean() returns error notice when buffer is empty
ID: 23826 User updated by: jc at mega-bucks dot co dot jp Reported By: jc at mega-bucks dot co dot jp Status: Closed Bug Type: Documentation problem -Operating System: ANY +Operating System: Red Hat Linux 8.0 PHP Version: 4.3.2RC4 Assigned To: helly New Comment: I totally understand your point of view. It's just that in my opinion if an E_NOTICE is generated then it probably means there is something wrong with my code [1]. If there is nothing wrong with calling ob_end_clean() on an empty buffer, then why have it generate a notice? Using @ would get rid of the notice, but if I understand the documentation correctly for the use of @ then I won't catch any *real* errors messages, they'll just be ignored [2]. So basically my question/problem comes down to this. Why is ob_end_clean() generating a notice? It's generating a notice to tell you that you call the function on an empty output buffer. Why is it bothering telling me this? It's bothering to tell me because either a) this is wrong and I shouldn't be doing it or b) it's being friendly and thinks it should let me know that I did something that I probably didn't intend to do. So is it case A (an error) or case B (possible poor programming). If it's case A then an ERROR should be generated, not a notice. If it's case B then #1- I can understand the logic being a notice for an uninitialized variable, but the output buffer is something generated by PHP in the backgroud, so it's not like I am trying to use something I didn't initialize ... #2- there should be a way for me to prevent the generation of "possible sloppy programming" friendly notices by checking beforehand that the buffer is not empty if it is deemed that this friendly notice is valid. And the prevention of these notices shold not interfere with the generation of *real* ERROR messages ... Just my 2 cents ;) [1] http://jp.php.net/manual/en/language.operators.errorcontrol.php Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why. [2] http://jp.php.net/manual/en/ref.errorfunc.php NOTICE messages will warn you about possibls bugs in your code. [...] Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. Previous Comments: [2003-05-27 13:25:16] [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 1) It is a notice and not an error 2) this notice tells you: you are doing unnecessary stuff 3) to clear all buffers do: while(@ob_end_clean()); [2003-05-27 10:12:58] [EMAIL PROTECTED] Why do you want to check before calling ob_end_clean()? It seems you simply want to call that then why not @ob_end_clean()? ------------------------ [2003-05-27 03:19:41] jc at mega-bucks dot co dot jp Ok. I understand the "bug fix" but that fix now causes another problem ... I have a custom error handler with the following code: $buffer = ob_get_contents(); ob_end_clean(); The call to ob_end_clean() will throw a notice if the buffer if empty, which will cause the error handler to either fail or call itself again (possibly infinitely?). So just to be clear, it seems you are saying that *technically* calling ob_end_clean() on an empty buffer is incorrect? If this is so, what is the proprer way of checking if the buffer is empty before calling ob_end_clean()? If there is a way of checking wether the buffer is empty or not then all is fine, if not then there is a problem ;) [2003-05-27 03:10:02] [EMAIL PROTECTED] You don't need to submit anymore bug reports.. And I meant with that crash preventing that it now throws an error and returns false, reviously when it didn't check the buffer, it just crashed. (that was the fix) ------------ [2003-05-27 02:23:47] jc at mega-bucks dot co dot jp >The notice was added to prevent it from crashing with empty buffers I must be missing something ... how does throwing a notice prevent anything from crashing? Or do you mean there is absolutely no way to check that the output bu
