Re: [PHP-DOC] Re: Zend API documentation to be moved to the phpdoc repository
On Tue, 12 Oct 2004, Aidan Lister wrote: > > I propose moving the Zend API docs to phpdoc/en/zendapi, but we need to > > make up a good folder structure. We need the XML files, but not simpler > > then Extending_Zend_xml, and we also need the figures and source > > examples in some sensible folder structure. I also don't know whether it > > would be better to move on the CVS server (retaining history), or just > > copy-add-commit-remove_on_old_file... > > > > Goba > > Why don't we stick it in phpdoc/en/chapters/zendapi and move the streams > stuff into phpdoc/en/chapters/streams? > > As for the structure relative to this directory, can't we keep the current > directory structure on the zend site? > > I'd like to see the CVS files copied across, retaining the history. The history is pretty much empty, so there is no good reason for doing that. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
[PHP-DOC] [PATCH] preg_match and preg_match_all
Documentation on preg_match and preg_match_all incorrectly describes meaning of offset parameter. Using offset parameter is NOT equivalent to passing substr($subject, $offset) to preg_match in place of the subject string. Although I have karma to commit the patch, I would like it to be "approved" first, since I never commited to "en" tree. Index: preg-match-all.xml === RCS file: /repository/phpdoc/en/reference/pcre/functions/preg-match-all.xml,v retrieving revision 1.13 diff -u -r1.13 preg-match-all.xml --- preg-match-all.xml 3 Aug 2004 15:51:10 - 1.13 +++ preg-match-all.xml 12 Oct 2004 06:35:21 - @@ -131,13 +131,23 @@ Normally, the search starts from the beginning of the subject string. The optional parameter offset can be used to specify - the alternate place from which to start the search. It is equivalent to - passing substr($subject, $offset) to - preg_match in place of the subject string. + the alternate place from which to start the search. The offset parameter is available since PHP 4.3.3. + + + Using offset is not equivalent to + passing substr($subject, $offset) to + preg_match_all in place of the subject string, + because pattern can contain assertions such as + ^, $ or + (?<=x). See preg_match for + examples. + + + Returns the number of full pattern matches (which might be zero), or &false; if an error occurred. Index: preg-match.xml === RCS file: /repository/phpdoc/en/reference/pcre/functions/preg-match.xml,v retrieving revision 1.15 diff -u -r1.15 preg-match.xml --- preg-match.xml 10 Aug 2004 16:30:20 - 1.15 +++ preg-match.xml 12 Oct 2004 06:35:24 - @@ -51,12 +51,71 @@ Normally, the search starts from the beginning of the subject string. The optional parameter offset can be used to specify - the alternate place from which to start the search. It is equivalent to - passing substr($subject, $offset) to - preg_match in place of the subject string. + the alternate place from which to start the search. The offset parameter is available since PHP 4.3.3. + + + Using offset is not equivalent to + passing substr($subject, $offset) to + preg_match in place of the subject string, because + pattern can contain assertions such as + ^, $ or + (?<=x). Compare : + + + + + + + will produce + + + + + + and + + + + + + will produce + + + + + + preg_match returns the number of times
[PHP-DOC] cvs: phpdoc /en/reference/memcache reference.xml
tony2001Tue Oct 12 00:40:04 2004 EDT
Modified files:
/phpdoc/en/reference/memcache reference.xml
Log:
fix example syntax
http://cvs.php.net/diff.php/phpdoc/en/reference/memcache/reference.xml?r1=1.3&r2=1.4&ty=u
Index: phpdoc/en/reference/memcache/reference.xml
diff -u phpdoc/en/reference/memcache/reference.xml:1.3
phpdoc/en/reference/memcache/reference.xml:1.4
--- phpdoc/en/reference/memcache/reference.xml:1.3 Tue Aug 3 21:56:31 2004
+++ phpdoc/en/reference/memcache/reference.xml Tue Oct 12 00:40:04 2004
@@ -1,5 +1,5 @@
-
+
Memcache Functions
Memcache
@@ -65,7 +65,7 @@
$tmp_object->str_attr = 'test';
$tmp_object->int_attr = 123;
-$memcache->set('key', $tmp_object, 10) or die ("Failed to save data at the server");
+$memcache->set('key', $tmp_object, false, 10) or die ("Failed to save data at the
server");
echo "Store data in the cache (data will expire in 10 seconds)\n";
$get_result = $memcache->get('key');
[PHP-DOC] Re: Zend API documentation to be moved to the phpdoc repository
> I propose moving the Zend API docs to phpdoc/en/zendapi, but we need to > make up a good folder structure. We need the XML files, but not simpler > then Extending_Zend_xml, and we also need the figures and source > examples in some sensible folder structure. I also don't know whether it > would be better to move on the CVS server (retaining history), or just > copy-add-commit-remove_on_old_file... > > Goba Why don't we stick it in phpdoc/en/chapters/zendapi and move the streams stuff into phpdoc/en/chapters/streams? As for the structure relative to this directory, can't we keep the current directory structure on the zend site? I'd like to see the CVS files copied across, retaining the history. Aidan
[PHP-DOC] #30379 [Bgs]: Example of Exception $e is Incorrect
ID: 30379
Updated by: [EMAIL PROTECTED]
Reported By: hans at nyphp dot com
Status: Bogus
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Yep, we have not rebuilt the manual yet. It should appear in the next
couple of days.
Previous Comments:
[2004-10-11 15:58:59] hans at nyphp dot com
Thanks Aidan. Please note, however, that this page:
http://www.php.net/manual/en/language.oop5.magic.php
Is empty.
And thanks for changing the example to getMessage(). I think depending
on toString for examples can cause confusion for the reasons you
mention.
Thanks again,
H
[2004-10-11 08:12:22] [EMAIL PROTECTED]
__toString has complicated (somewhat confusing) behaviour.
echo $e; // calls __toString
echo 'text', $e; // calls __toString
echo 'text'. $e; // doesn't call __toString
echo (string) $e; // doesn't call __toString
This is documented on the __toString page:
http://www.php.net/manual/en/language.oop5.magic.php
This behaviour may change in PHP 5.1
Also note: I've updated the exceptions page to call the getMessage
method, as it's more appropriate.
[2004-10-10 18:21:02] hans at nyphp dot com
While the _toString() should be called, in PHP 5.0.2 echoing an object,
$e of class Exception, doesn't always call the _toString() method.
So perhaps this is more than a documentation problem. For example,
given this catch{} block:
catch( Exception $e ) {
$ref = new ReflectionObject($e);
echo var_export($ref->getMethods(),1);
echo "My Error: ".$e;
}
This outputs (shortended form):
array (
...
8 =>
class ReflectionMethod {
public $name = '__toString';
public $class = 'Exception';
},
)
My Error: Object id #3
H
[2004-10-10 09:40:40] [EMAIL PROTECTED]
`echo $e` will call the exception classes __toString method. This will
show more information than just getMessage(). This isn't a mistake.
However, the docs are not very good - I'll have a look at them today.
[2004-10-10 06:33:43] hans at nyphp dot com
Description:
On the page that gives examples of how to use Exceptions:
http://www.php.net/manual/en/language.oop5.exceptions.php
The usage of catch() is incorrect in the examples. This code:
catch (Exception $e) {
echo "Caught exception: ", $e, "\n";
}
Would echo something like:
Caught exception: Object id #3
I cannot believe this is the desired output. This code:
catch (Exception $e) {
echo "Caught exception: ", $e->getMessage(), "\n";
}
Would provide the expected output:
Caught exception: Always throw this error
In other words, all exception code examples with echo statements of $e
should contain $e->getMessage() rather than just echoing $e.
Hans
--
Edit this bug report at http://bugs.php.net/?id=30379&edit=1
[PHP-DOC] #25921 [Com]: buggy example
ID: 25921 Comment by: rhuddleston at cavtel dot com Reported By: corinl at gmx dot de Status: No Feedback Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: I just ran into this same problem... Upgraded to Windows 2003 Directory server and now all my LDAP queries are broken. Return Warning Operations error. Yet running ldap from CLI is good.. Did notice that Win 2k3 is retuning an extra tcp sequence containing what appear to be commented out references to other LDAP search strings? Referral!! I tried to use the LDAP_OPT_REFERRALS but no luck - HELP! Previous Comments: [2004-09-24 01:00:05] phpdoc at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-09-16 15:50:40] [EMAIL PROTECTED] Please explain what exactly do you miss in the documentation. [2003-10-20 09:32:53] [EMAIL PROTECTED] Besides the doc problem, it may also be a "real" bug. Following draft-ietf-ldapext-ldap-c-api-xx.txt: LDAP_OPT_REFERRALS (0x08) [..] By default, this option is ON. Is this option ON by default in PHP or not? Following this draft it should be, when not I consider this a bug. Maybe it is a good idea to add the default options set by PHP to ldap_set_option/ldap_get_option. [2003-10-20 08:40:31] bugs dot php dot net at phrenetic dot to Then this is a documentation bug. http://se.php.net/manual/en/function.ldap-search.php and http://se.php.net/manual/en/function.ldap-connect.php doesn't say anything about this. [2003-10-20 08:13:26] [EMAIL PROTECTED] That's not workaround, that's how you're supposed to do it. 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/25921 -- Edit this bug report at http://bugs.php.net/?id=25921&edit=1
[PHP-DOC] #30402 [Bgs->Csd]: windows binary has wrong name
ID: 30402 User updated by: cleanthes at gmail dot com Reported By: cleanthes at gmail dot com -Status: Bogus +Status: Closed Bug Type: Documentation problem Operating System: Windows PHP Version: 5.0.2 New Comment: I can't either. I guess it was fixed. Thanks. Previous Comments: [2004-10-11 21:00:18] [EMAIL PROTECTED] Assuming that you are refering to the 'us2' mirror, I couldn't reproduce your problem. [2004-10-11 20:00:39] cleanthes at gmail dot com Description: The Hurricane Electric download site sends a zip file named php6.02 for php5.02 Windows binary. The contents seem to be good, but the name ought to be fixed. -- Edit this bug report at http://bugs.php.net/?id=30402&edit=1
[PHP-DOC] #30402 [Opn->Bgs]: windows binary has wrong name
ID: 30402 Updated by: [EMAIL PROTECTED] Reported By: cleanthes at gmail dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: Windows PHP Version: 5.0.2 New Comment: Assuming that you are refering to the 'us2' mirror, I couldn't reproduce your problem. Previous Comments: [2004-10-11 20:00:39] cleanthes at gmail dot com Description: The Hurricane Electric download site sends a zip file named php6.02 for php5.02 Windows binary. The contents seem to be good, but the name ought to be fixed. -- Edit this bug report at http://bugs.php.net/?id=30402&edit=1
Re: [PHP-DOC] Building manual
On Mon, 11 Oct 2004, Jakub Vrana wrote: > Hello Derick! If you write to me personally, use my email addres as "To" and "Cc" phpdoc, you'll have a faster answer then. > I'm not sure who is the person responsible for building the manual but I > guess it's you :-). Would it be possible to build manual little more > often - e.g. twice a month? I know that there are maybe some problems > which I don't see - e.g. build errors in other languages. I am asking > you (or whoever) just because there are some bug reports regarding to > old manual and because usual bug reporters can't verify if the manual > change was correct in their eyes. I started a build this morning, will check tommorow if it worked. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
[PHP-DOC] #30402 [NEW]: windows binary has wrong name
From: cleanthes at gmail dot com Operating system: Windows PHP version: 5.0.2 PHP Bug Type: Documentation problem Bug description: windows binary has wrong name Description: The Hurricane Electric download site sends a zip file named php6.02 for php5.02 Windows binary. The contents seem to be good, but the name ought to be fixed. -- Edit bug report at http://bugs.php.net/?id=30402&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30402&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30402&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30402&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30402&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30402&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30402&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30402&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30402&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30402&r=support Expected behavior: http://bugs.php.net/fix.php?id=30402&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30402&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30402&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30402&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30402&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30402&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30402&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30402&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30402&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30402&r=mysqlcfg
[PHP-DOC] Re: User Notes - Delete Reason
> I have committed your patch, but I beleive it will result in broken > links in some mail clients, due to too long lines on the > delete-with-reason links. Thanks Goba. Everyone: any suggestions for this problem? We could implement a shortened URL handler on master.php.net, but I doubt that would go over well with the regular master maintainers. TinyURL (or alike) would work, but I don't like depending on a third party. I'd like to completely re-work the notes process, on docweb, someday.. maybe this should wait. I think having short urls on the master server would go well with the maintainers. They only need to set a 404 handler and the PHP code can handle everything. Goba
[PHP-DOC] #30399 [NEW]: "Comparing strings" manual page
From: [EMAIL PROTECTED] Operating system: PHP version: 4.3.9 PHP Bug Type: Documentation problem Bug description: "Comparing strings" manual page Description: After studying some string issues I think we need one more page in manual about strings comparison with a link to/from strcmp. Few confusing examples from user-notes on http://www.php.net/manual/en/language.types.string.php And I haven't found any clear answer about is === operator equal to strcmp() if two arguments are strings with numbers in the beginning? Many coders use "==" instead of "strcmp" and there should be warning somewhere in manual about possible problems that could arise due to such misuse. See also: http://bugs.php.net/bug.php?id=28200 Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=30399&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30399&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30399&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30399&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30399&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30399&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30399&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30399&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30399&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30399&r=support Expected behavior: http://bugs.php.net/fix.php?id=30399&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30399&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30399&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30399&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30399&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30399&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30399&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30399&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30399&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30399&r=mysqlcfg
[PHP-DOC] Re: User Notes - Delete Reason
Gabor Hojtsy wrote: > I have committed your patch, but I beleive it will result in broken > links in some mail clients, due to too long lines on the > delete-with-reason links. > Thanks Goba. Everyone: any suggestions for this problem? We could implement a shortened URL handler on master.php.net, but I doubt that would go over well with the regular master maintainers. TinyURL (or alike) would work, but I don't like depending on a third party. I'd like to completely re-work the notes process, on docweb, someday.. maybe this should wait. S
[PHP-DOC] Re: User Notes - Delete Reason
Hi Sean, I've recently started keeping an eye on user notes, and think it would useful to maintain a simple archive of note deletion "reasons". Deleting can seem arbitrary without this sort of functionality. I updated my checkout of master-web (Wez told me that systems@ is probably the best place to submit patches to this module, as commits go there) with a few simple reasons. The regular mailing list archives will take care of reason archiving with this patch: http://www.phpdoc.info/master-web-notes-reason.patch If more reasons are requested, they can be added, easily. I don't have a working installation of php-master-web, so this patch is by-eye only (untested). Please let me know if I've created bugs, or if there's a better way to implement this functionality. I'm open to discussion on implementation. If all is good, could someone with the appropriate karma commit this? I have committed your patch, but I beleive it will result in broken links in some mail clients, due to too long lines on the delete-with-reason links. Goba
[PHP-DOC] #30386 [Asn->Csd]: STREAM_CLIENT_ASYNC_CONNECT not working
ID: 30386
Updated by: [EMAIL PROTECTED]
Reported By: vnegrier at esds dot com
-Status: Assigned
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux 2.4
PHP Version: 5.0.2
Assigned To: nlopess
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-10-11 01:20:24] [EMAIL PROTECTED]
You need to use STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT for
the flags parameter.
STREAM_CLIENT_CONNECT is the default flag value which means "perform
the connect() syscall". STREAM_CLIENT_ASYNC_CONNECT is a modifier for
this which means "when connect() is called, do it async"
Making this a documentation problem.
[2004-10-10 23:49:06] vnegrier at esds dot com
Description:
when I use the STREAM_CLIENT_ASYNC_CONNECT flag to my
stream_socket_client() call, it just doesn't connect() at all.
Reproduce code:
---
Actual result:
--
using strace on the following script gives :
write(1, "trying ...\n", 11trying ...
)= 11
rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
nanosleep({10, 0}, {10, 0}) = 0
in other words the connect() syscall is never called at all between the
echo and sleep.
on the other hand, when I remove STREAM_CLIENT_ASYNC_CONNECT, connect()
is called.
--
Edit this bug report at http://bugs.php.net/?id=30386&edit=1
[PHP-DOC] #30378 [Opn->Csd]: Random results with ctype_digit
ID: 30378 Updated by: [EMAIL PROTECTED] Reported By: guth at fiifo dot u-psud dot fr -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 5CVS-2004-10-10 (dev) 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. "... behave exactly like their C counterparts from ctype.h. It means that if you pass an integer smaller than 256 it will use the ASCII value of it to see if it fits in the specified range (digits are in 0x30-0x39). If the number is between -128 (inclusive) and 0 then 256 will be added and the check will be done on that." Previous Comments: [2004-10-11 07:56:30] [EMAIL PROTECTED] This is correct behavior though, as the numbers are automatically converted to strings in PHP, that's why it is called a losely-typed language. Though the manual should mention that if you pass an integer smaller than 256 it will use the ascii value of it to see if it fits in the specified range (digits are in 0x30-0x39). If the number is between -128 (inclusive) and 0 then 256 will be added and the check will be done on that again. [2004-10-10 00:15:45] guth at fiifo dot u-psud dot fr Description: See the following code : Reproduce code: --- echo "" | php echo "" | php Expected result: The prototype of this function is bool ctype_digit ( string text), so i expected : bool(false) bool(false) Actual result: -- bool(false) bool(true) -- Edit this bug report at http://bugs.php.net/?id=30378&edit=1
[PHP-DOC] Building manual
Hello Derick! I'm not sure who is the person responsible for building the manual but I guess it's you :-). Would it be possible to build manual little more often - e.g. twice a month? I know that there are maybe some problems which I don't see - e.g. build errors in other languages. I am asking you (or whoever) just because there are some bug reports regarding to old manual and because usual bug reporters can't verify if the manual change was correct in their eyes. Jakub Vrana
[PHP-DOC] #30386 [Opn->Asn]: STREAM_CLIENT_ASYNC_CONNECT not working
ID: 30386
Updated by: [EMAIL PROTECTED]
Reported By: vnegrier at esds dot com
-Status: Open
+Status: Assigned
Bug Type: Documentation problem
Operating System: Linux 2.4
PHP Version: 5.0.2
-Assigned To:
+Assigned To: nlopess
Previous Comments:
[2004-10-11 01:20:24] [EMAIL PROTECTED]
You need to use STREAM_CLIENT_ASYNC_CONNECT|STREAM_CLIENT_CONNECT for
the flags parameter.
STREAM_CLIENT_CONNECT is the default flag value which means "perform
the connect() syscall". STREAM_CLIENT_ASYNC_CONNECT is a modifier for
this which means "when connect() is called, do it async"
Making this a documentation problem.
[2004-10-10 23:49:06] vnegrier at esds dot com
Description:
when I use the STREAM_CLIENT_ASYNC_CONNECT flag to my
stream_socket_client() call, it just doesn't connect() at all.
Reproduce code:
---
Actual result:
--
using strace on the following script gives :
write(1, "trying ...\n", 11trying ...
)= 11
rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
nanosleep({10, 0}, {10, 0}) = 0
in other words the connect() syscall is never called at all between the
echo and sleep.
on the other hand, when I remove STREAM_CLIENT_ASYNC_CONNECT, connect()
is called.
--
Edit this bug report at http://bugs.php.net/?id=30386&edit=1
[PHP-DOC] #30379 [Bgs]: Example of Exception $e is Incorrect
ID: 30379
User updated by: hans at nyphp dot com
Reported By: hans at nyphp dot com
Status: Bogus
Bug Type: Documentation problem
Operating System: Irrelevant
PHP Version: Irrelevant
New Comment:
Thanks Aidan. Please note, however, that this page:
http://www.php.net/manual/en/language.oop5.magic.php
Is empty.
And thanks for changing the example to getMessage(). I think depending
on toString for examples can cause confusion for the reasons you
mention.
Thanks again,
H
Previous Comments:
[2004-10-11 08:12:22] [EMAIL PROTECTED]
__toString has complicated (somewhat confusing) behaviour.
echo $e; // calls __toString
echo 'text', $e; // calls __toString
echo 'text'. $e; // doesn't call __toString
echo (string) $e; // doesn't call __toString
This is documented on the __toString page:
http://www.php.net/manual/en/language.oop5.magic.php
This behaviour may change in PHP 5.1
Also note: I've updated the exceptions page to call the getMessage
method, as it's more appropriate.
[2004-10-10 18:21:02] hans at nyphp dot com
While the _toString() should be called, in PHP 5.0.2 echoing an object,
$e of class Exception, doesn't always call the _toString() method.
So perhaps this is more than a documentation problem. For example,
given this catch{} block:
catch( Exception $e ) {
$ref = new ReflectionObject($e);
echo var_export($ref->getMethods(),1);
echo "My Error: ".$e;
}
This outputs (shortended form):
array (
...
8 =>
class ReflectionMethod {
public $name = '__toString';
public $class = 'Exception';
},
)
My Error: Object id #3
H
[2004-10-10 09:40:40] [EMAIL PROTECTED]
`echo $e` will call the exception classes __toString method. This will
show more information than just getMessage(). This isn't a mistake.
However, the docs are not very good - I'll have a look at them today.
[2004-10-10 06:33:43] hans at nyphp dot com
Description:
On the page that gives examples of how to use Exceptions:
http://www.php.net/manual/en/language.oop5.exceptions.php
The usage of catch() is incorrect in the examples. This code:
catch (Exception $e) {
echo "Caught exception: ", $e, "\n";
}
Would echo something like:
Caught exception: Object id #3
I cannot believe this is the desired output. This code:
catch (Exception $e) {
echo "Caught exception: ", $e->getMessage(), "\n";
}
Would provide the expected output:
Caught exception: Always throw this error
In other words, all exception code examples with echo statements of $e
should contain $e->getMessage() rather than just echoing $e.
Hans
--
Edit this bug report at http://bugs.php.net/?id=30379&edit=1
[PHP-DOC] #30316 [Opn->Csd]: Docs are wrong: multiple random salts supplied automatically
ID: 30316 Updated by: [EMAIL PROTECTED] Reported By: drachma60 at ml1 dot net -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 4.3.8 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. "If the salt argument is not provided, one will be randomly generated by PHP each time you call this function." Previous Comments: [2004-10-11 04:19:38] drachma60 at ml1 dot net Hi vrana, Yes, I agree, there is an "If you are using the supplied salt" section in the manual. However, I stand by my claim that the documentation does not correctly describe the current behavior of the crypt function. In my sample code, I am not providing a salt. Therefore, according to the documentation: "If the salt argument is not provided, one will be randomly generated by PHP" "If you are using the supplied salt, you should be aware that the salt is generated once. If you are calling this function recursively, this may impact both appearance and security." The "supplied salt" is the "randomly generated salt". If the supplied salt were only generated once per PHP invocation, then all the lines of the result would be the same. However, it is obvious that the generated crypt lines are not identincal. They are different. Therefore, even though I am NOT supplying a salt to crypt, crypt is regenerating a new (and different) random salt each time I call it. This is not what the documentation describes. This regenerting behavior is the preferred behavior in that it is more secure. Moreover, this is the behavior specifically requested by bug 8080. However, the documentation describes the pre bug 8080 behavior. The documentation is incorrect. Thanks again! [2004-10-04 12:07:39] [EMAIL PROTECTED] There is "If you are using the supplied salt" in the manual. In your example, you are not supplying the salt but using the default one. I changed only recursively to repeatedly. [2004-10-04 07:45:58] drachma60 at ml1 dot net Description: http://us2.php.net/manual/en/function.crypt.php says: "If you are using the supplied salt, you should be aware that the salt is generated once. If you are calling this function recursively, this may impact both appearance and security." However, this does NOT seem to be the case, at least NOT on FreeBSD where crypt uses md5 by default. (Aside: Also, how would I call crypt "recursively"? "repeatedly" I can understand. But not "recursively", as crypt is not calling itself, nor can I (via PHP code) rewrite crypt to call itself.) Thanks! P.S. It looks like the documentation may have been correct before "bug" 8080 was fixed in December of 2000. Reproduce code: --- Expected result: $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 $1$salt$qJH7.N4xYta3aEG/dfqo/0 (Summary: I would expect all the salts to be the same, as per the documentation.) Actual result: -- $1$49EUp1Z7$o9UbbesjLIgng.AMtBhuC0 $1$ppH4o1pX$LWrm5Lk6RIxVdNnR2ow741 $1$PEKufg9F$.qqFw6E2IlueP08IV2MQa0 $1$9agtuCbw$DuMMRD7ybYuB5OBmlw87E/ $1$uzXF0rxF$3V8.0dzVaxVSEh6OgoFtF0 $1$MGg.lgdp$QGmQ68mkdiDDnIDRoAPa20 $1$ZDIvcKNU$1tpYj4x63Py6NKQlvWCD21 $1$rGzlQCSP$M8mRQH4VlNU2cDfb8Y6ru. $1$dKYZm7GZ$fQB58ZSFxm60e7Vovtma/. $1$tyR3/3kx$uw14iqFovhETlgWfdicro0 (Summary: As you can see, the salts are different.) -- Edit this bug report at http://bugs.php.net/?id=30316&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/strings/functions crypt.xml
vrana Mon Oct 11 09:49:34 2004 EDT Modified files: /phpdoc/en/reference/strings/functions crypt.xml Log: Clarify (bug #30316) http://cvs.php.net/diff.php/phpdoc/en/reference/strings/functions/crypt.xml?r1=1.9&r2=1.10&ty=u Index: phpdoc/en/reference/strings/functions/crypt.xml diff -u phpdoc/en/reference/strings/functions/crypt.xml:1.9 phpdoc/en/reference/strings/functions/crypt.xml:1.10 --- phpdoc/en/reference/strings/functions/crypt.xml:1.9 Mon Oct 4 06:08:00 2004 +++ phpdoc/en/reference/strings/functions/crypt.xml Mon Oct 11 09:49:32 2004 @@ -1,5 +1,5 @@ - + @@ -23,7 +23,7 @@ If the salt argument is not provided, one will be randomly - generated by PHP. + generated by PHP each time you call this function. Some operating systems support more than one type of encryption. In
[PHP-DOC] Zend API documentation to be moved to the phpdoc repository
Hi, This is a long standing TODO item. Zeev finally found the time to think about it a bit, and agreed that the Zend API documentation is going to be moved to phpdoc. Here is the relevant excerpt from his mail: | We're willing to reassign the copyright to the PHP Doc team with | just one condition - we'd like there to be an attribution to | Zend, mentioning that the docs are based on an initial | contribution by Zend Technologies. | | I hope this was worth the wait :) Now this mail gets publicly archived, and so Zeev can confirm it with a public reply. What do we gain from moving the ZendAPI docs to phpdoc? - one build system instead of two - more visibility for people to rewrite / improve on it, being in the recognized phpdoc module - more opennes (the content is still going to be licensed under the same license as before, which is the same as the license phpdoc uses, but the license holder is going to change from Zend to the PHP Doc team) - development docs get into the same place (streams development stuff is in phpdoc too) - technically it is going to be possible for translations to translate the Zend API docs (although it is not advised now) - note that someone from the Russian team even translated some files and committed them to the ZendAPI repository I propose moving the Zend API docs to phpdoc/en/zendapi, but we need to make up a good folder structure. We need the XML files, but not simpler then Extending_Zend_xml, and we also need the figures and source examples in some sensible folder structure. I also don't know whether it would be better to move on the CVS server (retaining history), or just copy-add-commit-remove_on_old_file... Goba
