[PHP-DOC] #20814 [Ana->Csd]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Documentation problem Operating System: all PHP Version: 4.4.0-dev New Comment: This behavior has now been documented: http://cvs.php.net/cvs.php/phpdoc/en/language/types.xml Thanks for the report :) Previous Comments: [2003-01-21 00:45:31] [EMAIL PROTECTED] This has been documented but it could also mention, that if the end tag of heredoc is not 'clean', ie. it's not exactly 'heredoc;' like in the example above, then it is NOT considered the end tag. ZE will ignore it and continued looking for the end tag.. and as it is not found, there will be a parse error, with line number being the last line of the script. [2002-12-04 14:58:11] [EMAIL PROTECTED] To clarify the line mismatch: AFAIK it's the same as a missing '}' in if/else. It will report on the __last__ expected '}', while the error will intuitively start on the __first__ unclosed '}'. The '$' is 'end' as in regexps. [2002-12-04 11:24:55] [EMAIL PROTECTED] To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = "variable"; $someVariable = << text text $variable testing here document hereDocument; // closing comment or just whitespace echo $someVariable; After the closing "hereDocument;" if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/language types.xml
philip Tue Jan 21 02:27:51 2003 EDT Modified files: /phpdoc/en/language types.xml Log: Explain heredoc closing identifier error a little more. This closes bug #20814. Index: phpdoc/en/language/types.xml diff -u phpdoc/en/language/types.xml:1.104 phpdoc/en/language/types.xml:1.105 --- phpdoc/en/language/types.xml:1.104 Tue Jan 21 02:17:32 2003 +++ phpdoc/en/language/types.xmlTue Jan 21 02:27:50 2003 @@ -1,5 +1,5 @@ - + Types @@ -781,6 +781,13 @@ the closing identifier must be a newline as defined by your operating system. This is \r on Macintosh for example. + + + If this rule is broken and the closing identifier is not "clean" + then it's not considered to be a closing identifier and PHP + will continue looking for one. If in this case a proper closing + identifier is not found then a parse error will result with the + line number being at the end of the script. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/language types.xml
philip Tue Jan 21 02:17:32 2003 EDT Modified files: /phpdoc/en/language types.xml Log: Added , and missing CDATA's. Index: phpdoc/en/language/types.xml diff -u phpdoc/en/language/types.xml:1.103 phpdoc/en/language/types.xml:1.104 --- phpdoc/en/language/types.xml:1.103 Sat Jan 18 12:31:07 2003 +++ phpdoc/en/language/types.xmlTue Jan 21 02:17:32 2003 @@ -1,5 +1,5 @@ - + Types @@ -127,6 +127,7 @@ @@ -185,7 +187,9 @@ @@ -199,6 +203,7 @@ @@ -283,6 +289,7 @@ @@ -325,10 +333,12 @@ Integer literals @@ -336,6 +346,7 @@ @@ -368,6 +380,7 @@ @@ -410,9 +424,11 @@ @@ -467,7 +483,9 @@ @@ -511,7 +529,13 @@ specified using any of the following syntaxes: -$a = 1.234; $a = 1.2e3; $a = 7E-10; + Formally: @@ -641,6 +665,7 @@ @@ -841,10 +867,12 @@ @@ -865,6 +893,7 @@ +?> +]]> @@ -2031,8 +2112,12 @@ + @@ -2052,8 +2137,12 @@ above: + See the section titled String @@ -2070,8 +2159,12 @@ is to be cast. + @@ -2103,8 +2196,12 @@ the following are functionally equivalent: + @@ -2114,6 +2211,8 @@ the variable in double quotes. + -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #20814 [Ver->Ana]: reproducable, freaky parse error in 'here document' structure
ID: 20814 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Analyzed -Bug Type: Scripting Engine problem +Bug Type: Documentation problem Operating System: all PHP Version: 4.4.0-dev New Comment: This has been documented but it could also mention, that if the end tag of heredoc is not 'clean', ie. it's not exactly 'heredoc;' like in the example above, then it is NOT considered the end tag. ZE will ignore it and continued looking for the end tag.. and as it is not found, there will be a parse error, with line number being the last line of the script. Previous Comments: [2002-12-04 14:58:11] [EMAIL PROTECTED] To clarify the line mismatch: AFAIK it's the same as a missing '}' in if/else. It will report on the __last__ expected '}', while the error will intuitively start on the __first__ unclosed '}'. The '$' is 'end' as in regexps. [2002-12-04 11:24:55] [EMAIL PROTECTED] To clarify a few points: a) This is known and is both documented and is a current feature request: http://bugs.php.net/bug.php?id=8685 http://www.php.net/language.types.string#language.types.string.syntax.heredoc b) The error that's reported is odd, and looks something like this: Parse error: parse error, unexpected $ in test.php on line 42 Where 42 is, for example, on the last line of test.php even when the error is elsewhere. This error sorta makes sense in most cases (like a missing quote or closing brace) but IMHO not here. Maybe someone can briefly explain what PHP is thinking. c) Many have attempted to fix this and many more have reported it (a) but it appears to be almost impossible to fix and remains a feature request. Again, it is documented with a big fat warning. Am leaving as open as this mentions the strange error too (b), not just the known feature request. [2002-12-04 11:23:05] [EMAIL PROTECTED] [quick on the trigger]... scratch that last sentence ... I was going to point out that the closing tag has to be flush left but I think that is not a bug. [2002-12-04 11:04:39] [EMAIL PROTECTED] I've tested this on PHP 4.2.3 for OSX, Open BSD, Linux... If you leave any whitespace after the closing tag of a here document structure (not sure if that's what it is called, like in Perl) a parse error will occur but never for the correct line. This seems like a bug to me because a semi- colon should terminate the code allowing the programmer to put comments or whatever after the semi-colon. Here is an example: $variable = "variable"; $someVariable = << text text $variable testing here document hereDocument; // closing comment or just whitespace echo $someVariable; After the closing "hereDocument;" if you leave any whitespace (other than a carriage return) or text, a parse error is generated but the line number never leads you to the right place. This can be very confusing if you are working on a large class (like I was) and you left a tab or space after a closing tag. I'm not sure how consciously supported the here document structure is but this is worth addressing since here documents can be very useful for storing large variables containing HTML code with double and single quotes, for example. While I'm submitting this bug, I might as well point -- Edit this bug report at http://bugs.php.net/?id=20814&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #16227 [Com]: Using internal hash position is tricky.
ID: 16227
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: ANY
PHP Version: PHP4 only
New Comment:
Well, so is it fixed or is it not? This bug's status is still Open.
Previous Comments:
[2002-10-01 06:28:18] [EMAIL PROTECTED]
FYI. The bug is fixed. Current CVS version does not swap internal hash
position on assinment.
[2002-10-01 06:13:17] [EMAIL PROTECTED]
The issue is ZendEngine mess up hash position by assignment.
I'll open new one for this.
[2002-07-16 11:22:34] [EMAIL PROTECTED]
each() as a function does not know in which context it was called so it
just returns the 'current' element and advances the internal position
pointer, very similar to the java next_element() iterator (hope i got
the name right). when no more elements are left it returns false until
being reset
each() can not know that it was called from different loop runs so it
will return false forever until reset. one might
think about auto-reseting it after returning false once, but backwards
compatibility will be in our way once again here
the problem does not happen this way in java because there
next_element() advances the internal pointer before returning values
and you have to use first_element() to get
the first one (which implies a reset)
foreach uses a private copy of the array structure so it has its own
internal pointer which is recreated for every foreach instance so the
problem does occure here
[2002-03-23 20:44:45] [EMAIL PROTECTED]
Oops,
$arr = array('a', 'b', 'c');
does reset position :)
[2002-03-23 20:39:56] [EMAIL PROTECTED]
Both each() and foreach() uses internal hash position variable.
Difference is foreach() reset internal hash position to the first
element while each() does not.
A problematic behavior is an assignment resets internal hash
position. There are other cases programmer has to be careful about
internal hash position and reference counting feature.
In addition to that, it is _not_ intuitive that assignment as follows
$arr = array('a', 'b', 'c');
does not reset hash posiiton, while following assignment does reset
hash position.
$arr2 = $arr1;
Anyway, some internal hash posision behaviors are inconsistent and
_not_ intuitive at all. This would be really hard to find if a user
experience the problem. Therefore, it should be documented :)
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/16227
--
Edit this bug report at http://bugs.php.net/?id=16227&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/faq mailinglist.xml
philip Mon Jan 20 22:31:27 2003 EDT Modified files: /phpdoc/en/faq mailinglist.xml Log: Add the "how to ask smart questions" link a couple times although ideally it'd be mentioned on every manual page. Index: phpdoc/en/faq/mailinglist.xml diff -u phpdoc/en/faq/mailinglist.xml:1.13 phpdoc/en/faq/mailinglist.xml:1.14 --- phpdoc/en/faq/mailinglist.xml:1.13 Sat Feb 23 11:59:46 2002 +++ phpdoc/en/faq/mailinglist.xml Mon Jan 20 22:31:27 2003 @@ -1,5 +1,5 @@ - + Mailing lists Mailing lists @@ -110,6 +110,11 @@ can't find any information that helps you out you're more than welcome to use the mailing list. + + Before asking questions, you may want to read the paper on + How To Ask Questions The Smart + Way as this is a good idea for everyone. + @@ -141,6 +146,12 @@ Another important thing to remember is to summarize your problem on the subject line. A subject like "HELP M!!!" or "What is the problem here?" will be ignored by the majority of the readers. + + + And lastly, you're encouraged to read the paper on + How To Ask Questions The + Smart Way as this will be a great help for everyone, + especially yourself. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21783 [Opn]: cli execution doesn't find php.ini
ID: 21783 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: 4.3.0 New Comment: The text I'd suggest is something along these lines. I don't know the complete inner workings of PHP, so tweak it to reflect reality. On Unix systems, PHP uses the php.ini file specified when PHP was compiled. On Windows systems, PHP uses the php.ini from the same directory as the php.exe file you execute. This behavior can be modified by using the -c switch or by setting the PHPRC environment variable. See the Configuration page for more information. Thanks, --Dan Previous Comments: [2003-01-20 21:05:31] [EMAIL PROTECTED] On a related note, I heard rumors that as of 4.3.0 ini files such as php-cli.ini and php-cgi.ini are looked for first, is this true? If not found, php.ini is looked for. [2003-01-20 20:52:26] [EMAIL PROTECTED] Point taken :) A cross reference to the info about the location of php.ini file (/manual/en/configuration.php#configuration.file) should be inserted on features.commandline page. [2003-01-20 20:46:58] [EMAIL PROTECTED] Thank you for that link. None the less, people reading the features.commandline.php won't necessarily read the configuration.php page. Gee, take me for example! :) I spent a significant amount of time trying to figure out what was going on. Checked the command line page in the manual, all of the user comments, the newsgroup archives and the bug database. All of which turned up nothing, hence my bug report. So, a simple mention of the situation and a cross reference link to configuration.php would be helpful. Heck, I'm fairly PHP literate and a good sleuth, but wound up using your time anyway. This minor documentation tweak will save everyone grief in the long run. Of course, I could add a user comment, but that doesn't have the same impact. Thanks for your consideration, --Dan [2003-01-20 19:51:29] [EMAIL PROTECTED] PHPRC environmental variable (and other ways of finding it) are documented at: http://www.php.net/manual/en/configuration.php#configuration.file [2003-01-20 19:44:22] [EMAIL PROTECTED] Okay. Then, can you please change this into a documentation bug? The features.commandline.php pages should really explain this. For the clarity of other people reading this, the simple, long-term solution is creating an environment variable named PHPRC and setting it to the path of where your php.ini file resides. For example, "c:\progra~1\php" Thanks, --Dan 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/21783 -- Edit this bug report at http://bugs.php.net/?id=21783&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21783 [Opn]: cli execution doesn't find php.ini
ID: 21783 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: 4.3.0 New Comment: On a related note, I heard rumors that as of 4.3.0 ini files such as php-cli.ini and php-cgi.ini are looked for first, is this true? If not found, php.ini is looked for. Previous Comments: [2003-01-20 20:52:26] [EMAIL PROTECTED] Point taken :) A cross reference to the info about the location of php.ini file (/manual/en/configuration.php#configuration.file) should be inserted on features.commandline page. [2003-01-20 20:46:58] [EMAIL PROTECTED] Thank you for that link. None the less, people reading the features.commandline.php won't necessarily read the configuration.php page. Gee, take me for example! :) I spent a significant amount of time trying to figure out what was going on. Checked the command line page in the manual, all of the user comments, the newsgroup archives and the bug database. All of which turned up nothing, hence my bug report. So, a simple mention of the situation and a cross reference link to configuration.php would be helpful. Heck, I'm fairly PHP literate and a good sleuth, but wound up using your time anyway. This minor documentation tweak will save everyone grief in the long run. Of course, I could add a user comment, but that doesn't have the same impact. Thanks for your consideration, --Dan [2003-01-20 19:51:29] [EMAIL PROTECTED] PHPRC environmental variable (and other ways of finding it) are documented at: http://www.php.net/manual/en/configuration.php#configuration.file [2003-01-20 19:44:22] [EMAIL PROTECTED] Okay. Then, can you please change this into a documentation bug? The features.commandline.php pages should really explain this. For the clarity of other people reading this, the simple, long-term solution is creating an environment variable named PHPRC and setting it to the path of where your php.ini file resides. For example, "c:\progra~1\php" Thanks, --Dan [2003-01-20 19:05:54] [EMAIL PROTECTED] This is how cli is designed to work (not to look for php.ini in the current working directory) and it won't change. You can achieve the desired behaviour by issuing: set PHPRC=. on the command line, or setting this environmental variable elsewhere in the system. 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/21783 -- Edit this bug report at http://bugs.php.net/?id=21783&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /entities faqurls.ent
philip Mon Jan 20 21:54:12 2003 EDT Modified files: /phpdoc/entitiesfaqurls.ent Log: A nice url about how to ask smart questions. This will come in handy :) Index: phpdoc/entities/faqurls.ent diff -u phpdoc/entities/faqurls.ent:1.10 phpdoc/entities/faqurls.ent:1.11 --- phpdoc/entities/faqurls.ent:1.10Fri Dec 6 17:31:45 2002 +++ phpdoc/entities/faqurls.ent Mon Jan 20 21:54:11 2003 @@ -1,6 +1,6 @@
[PHP-DOC] #21783 [WFx->Opn]: cli execution doesn't find php.ini
ID: 21783
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Wont fix
+Status: Open
-Bug Type: *Configuration Issues
+Bug Type: Documentation problem
-Operating System: Windows NT 4.0
+Operating System: Any
PHP Version: 4.3.0
New Comment:
Point taken :)
A cross reference to the info about the location of php.ini file
(/manual/en/configuration.php#configuration.file) should be inserted on
features.commandline page.
Previous Comments:
[2003-01-20 20:46:58] [EMAIL PROTECTED]
Thank you for that link. None the less, people reading the
features.commandline.php won't necessarily read the configuration.php
page.
Gee, take me for example! :) I spent a significant amount of time
trying to figure out what was going on. Checked the command line page
in the manual, all of the user comments, the newsgroup archives and the
bug database. All of which turned up nothing, hence my bug report.
So, a simple mention of the situation and a cross reference link to
configuration.php would be helpful.
Heck, I'm fairly PHP literate and a good sleuth, but wound up using
your time anyway. This minor documentation tweak will save everyone
grief in the long run.
Of course, I could add a user comment, but that doesn't have the same
impact.
Thanks for your consideration,
--Dan
[2003-01-20 19:51:29] [EMAIL PROTECTED]
PHPRC environmental variable (and other ways of finding it) are
documented at:
http://www.php.net/manual/en/configuration.php#configuration.file
[2003-01-20 19:44:22] [EMAIL PROTECTED]
Okay. Then, can you please change this into a documentation bug? The
features.commandline.php pages should really explain this.
For the clarity of other people reading this, the simple, long-term
solution is creating an environment variable named PHPRC and setting it
to the path of where your php.ini file resides. For example,
"c:\progra~1\php"
Thanks,
--Dan
[2003-01-20 19:05:54] [EMAIL PROTECTED]
This is how cli is designed to work (not to look for php.ini in the
current working directory) and it won't change.
You can achieve the desired behaviour by issuing:
set PHPRC=.
on the command line, or setting this environmental variable elsewhere
in the system.
[2003-01-20 17:29:50] [EMAIL PROTECTED]
Hi:
Please pardon the initial background if it's irrelevant, but I figured
it may come into play somehow...
Been using PHP for years, just fine. It's installed in
f:\progra~1\php. That dir is in my Path, so I keep the php.ini and
various dll's there to make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup
directory and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . "\n";
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . "\n";
Now I open up command line window and execute:
> cd progra~1\php
> php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
> cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one
directory level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit this bug report at http://bugs.php.net/?id=21783&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/faq general.xml
philip Mon Jan 20 21:49:04 2003 EDT Modified files: /phpdoc/en/faq general.xml Log: Add php5 to the versions faq. Index: phpdoc/en/faq/general.xml diff -u phpdoc/en/faq/general.xml:1.17 phpdoc/en/faq/general.xml:1.18 --- phpdoc/en/faq/general.xml:1.17 Tue Dec 18 10:42:48 2001 +++ phpdoc/en/faq/general.xml Mon Jan 20 21:49:03 2003 @@ -1,5 +1,5 @@ - + General Information General Information @@ -56,9 +56,12 @@ PHP/FI 2.0 is an early and no longer supported version of PHP. PHP 3 - is the successor to PHP/FI 2.0 and is a lot nicer. PHP 4 is the latest + is the successor to PHP/FI 2.0 and is a lot nicer. PHP 4 is the current generation of PHP, which uses the Zend - engine under the hood. + engine under the hood. PHP 5 uses Zend engine 2 which, among other + things, offers many additional OOP + features. PHP 5 is experimental. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/ibase/functions ibase-connect.xml
philip Mon Jan 20 21:39:20 2003 EDT Modified files: /phpdoc/en/reference/ibase/functionsibase-connect.xml Log: Fix bug introduced in last commit Index: phpdoc/en/reference/ibase/functions/ibase-connect.xml diff -u phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.3 phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.4 --- phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.3 Mon Jan 20 21:36:43 2003 +++ phpdoc/en/reference/ibase/functions/ibase-connect.xml Mon Jan 20 21:39:20 +2003 @@ -1,5 +1,5 @@ - + @@ -48,7 +48,7 @@
[PHP-DOC] cvs: phpdoc /en/reference/ibase/functions ibase-connect.xml
philip Mon Jan 20 21:36:44 2003 EDT Modified files: /phpdoc/en/reference/ibase/functionsibase-connect.xml Log: cleanup a bit, add example host to the example. This closes one user comment. Index: phpdoc/en/reference/ibase/functions/ibase-connect.xml diff -u phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.2 phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.3 --- phpdoc/en/reference/ibase/functions/ibase-connect.xml:1.2 Wed Apr 17 02:38:50 2002 +++ phpdoc/en/reference/ibase/functions/ibase-connect.xml Mon Jan 20 21:36:43 +2003 @@ -1,5 +1,5 @@ - + @@ -48,6 +48,8 @@
[PHP-DOC] cvs: phpdoc /entities global.ent
cortesi Mon Jan 20 19:36:24 2003 EDT Modified files: /phpdoc/entitiesglobal.ent Log: changing URL due to change of address of the site Index: phpdoc/entities/global.ent diff -u phpdoc/entities/global.ent:1.74 phpdoc/entities/global.ent:1.75 --- phpdoc/entities/global.ent:1.74 Thu Jan 16 04:38:30 2003 +++ phpdoc/entities/global.ent Mon Jan 20 19:36:24 2003 @@ -1,6 +1,6 @@
[PHP-DOC] #21785 [Opn]: Sybase Functions Needing Documentation
ID: 21785 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: 4.3.0 -Assigned To: +Assigned To: leon New Comment: BTW, I'll take stab at adding this documentation in the next month or so. I need to get back up to speed on working on the manual since it's been so long. Previous Comments: [2003-01-20 18:11:37] [EMAIL PROTECTED] Here are some functions needing documentation related to the SybaseCT extension. It looks like Timm Friebe added these back in August and he put up some documentation here: http://sitten-polizei.de/php/README.SYBASE.EN Here's a quick summary: void sybase_deadlock_retry_count(int retry_count) Sets deadlock retry count, same as the php.ini setting. array sybase_fetch_assoc(resource result) Fetch a row from result set indexed by column names only bool sybase_set_message_handler(mixed error_func) Set the error handler, to be called when a server message is raised. If error_func is NULL the handler will be deleted. int sybase_unbuffered_query(string query [, int link_id]) Send Sybase query and do not block. -- Edit this bug report at http://bugs.php.net/?id=21785&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21785 [NEW]: Sybase Functions Needing Documentation
From: [EMAIL PROTECTED] Operating system: PHP version: 4.3.0 PHP Bug Type: Documentation problem Bug description: Sybase Functions Needing Documentation Here are some functions needing documentation related to the SybaseCT extension. It looks like Timm Friebe added these back in August and he put up some documentation here: http://sitten-polizei.de/php/README.SYBASE.EN Here's a quick summary: void sybase_deadlock_retry_count(int retry_count) Sets deadlock retry count, same as the php.ini setting. array sybase_fetch_assoc(resource result) Fetch a row from result set indexed by column names only bool sybase_set_message_handler(mixed error_func) Set the error handler, to be called when a server message is raised. If error_func is NULL the handler will be deleted. int sybase_unbuffered_query(string query [, int link_id]) Send Sybase query and do not block. -- Edit bug report at http://bugs.php.net/?id=21785&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21785&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21785&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21785&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21785&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21785&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21785&r=support Expected behavior: http://bugs.php.net/fix.php?id=21785&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21785&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21785&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21785&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21785&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21785&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21785&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21785&r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] #18403 [Opn->Fbk]: changable directive information(ini_set)
[snip] > > Well, as we talked about this in the past, those > > files are not used at > > all, they are just exist... Maybe some script uses > > one of them, I cannot > > remember, but actually they have no use. > > Yep, mostly I look at the status.txt and the > funcsummary.txt to see what new functions have been > introduced in the source, and to see which ones have > yet to be documented. Something like that is useful > for writing documentation, but an XML solution like > the one you mention below would be nice too. > > > We talked > > at that particular > > March PHP meeting about having an XML format instead > > provided for > > download at php.net/download-docs for IDEs to use... > > I already have a > > method to generate that (using XSLT) so this would > > be the first thing to > > use xsltproc and not jade ;)) So it would also be > > nice to start > > experimenting with xslt without affecting the > > current system too much... > > Sure thing. If that can also generate the summaries > from the source, in such a way as to be make starting > up a new doc easy, that would be great indeed. Should > not be too difficult to cruft together a regex to > generate some skeletons for the undocumented > functions, it is just the time that is needed to > invest to create the code (which regretably will be in > short supply for me). The functable module in CVS essentially generates all the needed information (this is the base that zend.com/phpfunc/ uses). This generates every function in the source including the no documentation list. Also we have /scripts/make_proto.php which generates skeleton documentation for a new extension which includes documentation for every function in the extension. It also adds the &warn.undocumented.func; entity. These two beasts are a base for this megabeast you guys speak of. I am not the person for this job :) On a related note, Ilia is creating a script to compare prototypes from php4 source and the proto in phpdoc. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] #18403 [Opn->Fbk]: changable directive information (ini_set)
--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote: [...snip...] > Well, then it will going to be a php.in and it's > detection code will be > removed I guess, as the PHP source path, and the > phpdoc source path is > already known after ./configure, so there is no need > to complicate > things with using another detection algorithm.. Sure thing. I wrote that detection code so we can test the script right now w/o modifying the build process. If all looks Ok, then it will be a .in and will get its definitions from the configuration step. > > Also, look at the approach there. It might be > useful for making > > replacements for the funcsummary and funclist > scripts. > > Well, as we talked about this in the past, those > files are not used at > all, they are just exist... Maybe some script uses > one of them, I cannot > remember, but actually they have no use. Yep, mostly I look at the status.txt and the funcsummary.txt to see what new functions have been introduced in the source, and to see which ones have yet to be documented. Something like that is useful for writing documentation, but an XML solution like the one you mention below would be nice too. > We talked > at that particular > March PHP meeting about having an XML format instead > provided for > download at php.net/download-docs for IDEs to use... > I already have a > method to generate that (using XSLT) so this would > be the first thing to > use xsltproc and not jade ;)) So it would also be > nice to start > experimenting with xslt without affecting the > current system too much... Sure thing. If that can also generate the summaries from the source, in such a way as to be make starting up a new doc easy, that would be great indeed. Should not be too difficult to cruft together a regex to generate some skeletons for the undocumented functions, it is just the time that is needed to invest to create the code (which regretably will be in short supply for me). Cheers. = --- Jesus M. Castagnetto <[EMAIL PROTECTED]> __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17458 [Opn->Csd]: Can't compile with IMAP support
ID: 17458 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: BSDi 4.2/4.3 PHP Version: 4.2.1 New Comment: This problem has been addressed, the documentation has been updated so this conflict won't show up. See: http://cvs.php.net/cvs.php/phpdoc/en/reference/imap/reference.xml http://cvs.php.net/cvs.php/phpdoc/en/reference/imap/configure.xml Thanks for the report, and thanks to Ilia for describing how to solve it. Previous Comments: [2002-05-30 08:14:09] [EMAIL PROTECTED] Minor correction: The documentation is okay as long as you DO NOT copy the header files in /usr/include. So I guess a note about that would be enough. --Jani [2002-05-30 08:11:24] [EMAIL PROTECTED] If you have compiled c-client library yourself, point the PHP configure to that source directory. e.g. --with-imap=/usr/src/imap-2001a/ c-client has some header files which are named same as some unix header files are (unix.h for example). So documentation should be fixed. (ie. you should always use the source path and not install the library/header files anywhere) --Jani [2002-05-27 13:22:17] [EMAIL PROTECTED] Can't compile PHP 4.2.1 (or 4.2.0) with IMAP support on BSDi 4.2 or 4.3 uage_parser.c || echo './'`zend_language_parser.c In file included from zend.h:55, from zend_compile.h:24, from zend_language_parser.c:147: /usr/include/unix.h:182: syntax error before `MAILSTREAM' /usr/include/unix.h:193: syntax error before `*' /usr/include/unix.h:193: warning: data definition has no type or storage class /usr/include/unix.h:196: syntax error before `*' /usr/include/unix.h:197: syntax error before `*' /usr/include/unix.h:198: syntax error before `*' /usr/include/unix.h:199: syntax error before `*' /usr/include/unix.h:200: syntax error before `*' /usr/include/unix.h:201: syntax error before `*' /usr/include/unix.h:202: syntax error before `*' /usr/include/unix.h:202: syntax error before `*' /usr/include/unix.h:202: warning: data definition has no type or storage class /usr/include/unix.h:203: syntax error before `*' /usr/include/unix.h:204: syntax error before `*' /usr/include/unix.h:206: syntax error before `*' /usr/include/unix.h:207: syntax error before `*' /usr/include/unix.h:209: syntax error before `*' /usr/include/unix.h:210: syntax error before `*' /usr/include/unix.h:211: syntax error before `*' /usr/include/unix.h:212: syntax error before `*' /usr/include/unix.h:213: syntax error before `*' /usr/include/unix.h:214: syntax error before `*' /usr/include/unix.h:215: syntax error before `*' /usr/include/unix.h:216: syntax error before `*' /usr/include/unix.h:219: syntax error before `*' /usr/include/unix.h:221: syntax error before `DOTLOCK' /usr/include/unix.h:222: syntax error before `MAILSTREAM' /usr/include/unix.h:223: syntax error before `*' /usr/include/unix.h:224: syntax error before `*' /usr/include/unix.h:225: syntax error before `*' /usr/include/unix.h:226: syntax error before `*' /usr/include/unix.h:228: syntax error before `*' /usr/include/unix.h:229: syntax error before `*' And I can't use gmake because I get: Makefile:34: *** missing separator. Stop. PHP Configure line: ./configure --with-mysql --with-gettext --with-xml --with-ftp --with-apxs --with-gd=/usr/local --with-imap=/usr -- Edit this bug report at http://bugs.php.net/?id=17458&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/imap configure.xml reference.xml
philip Mon Jan 20 16:41:12 2003 EDT Modified files: /phpdoc/en/reference/imap reference.xml configure.xml Log: Update imap install docs as the current method will provide conflicts on some setups. This closes some user comments and closes bug #17458 Index: phpdoc/en/reference/imap/reference.xml diff -u phpdoc/en/reference/imap/reference.xml:1.10 phpdoc/en/reference/imap/reference.xml:1.11 --- phpdoc/en/reference/imap/reference.xml:1.10 Sat Nov 30 07:45:46 2002 +++ phpdoc/en/reference/imap/reference.xml Mon Jan 20 16:41:12 2003 @@ -1,5 +1,5 @@ - + IMAP, POP3 and NNTP functions IMAP @@ -23,46 +23,23 @@ and compile it. - You have to copy some files to make sure they are in your link path - (e.g.: /usr/local/lib/) and include directory - (e.g.: /usr/local/include). - The files to copy can be found in the source tree - under imap-200x/c-lient after a succesfull run of - make. Copy c-client.a - to /usr/local/lib/libc-client.a or some other - directory on your link path. + It's important that you do not copy the IMAP source files directly into + the system include directory as there may be conflicts. Instead, create + a new directory inside the system include directory, such as + /usr/local/imap-2000b/ (location and name + depend on your setup and IMAP version), and inside this new + directory create additional directories named lib/ + and include/. From the c-client + directory from your IMAP source tree, copy all the *.h + files into include/ and all the + *.c files into lib/. + Additionally when you compiled IMAP, a file named + c-client-a was created. Also put this in the + lib/ directory but rename it as + libc-client.a. - Make sure c-client.a ends up in your link path - under the name libc-client.a. - - - - Copy the following files to /usr/local/include or some - other directory in your include path. - - c-client.h - imap4r1.h - rfc822.h - mail.h - linkage.h - env.h - env_unix.h - fs.h - ftl.h - misc.h - nntp.h - nl.h - osdep.h - smtp.h - tcp.h - - - - - The name of env_unix.h depends on your OS. - Make sure to copy this files with following symlinks option. To build the c-client library with SSL or/and Kerberos support read the docs supplied with the package. @@ -145,14 +122,6 @@ by David Wood and Managing IMAP by Dianna Mullet & Kevin Mullet. - - - Crashes and startup problems of PHP may be encountered - when loading this extension in conjunction with the recode extension. - See the recode extension for more - information. - - Index: phpdoc/en/reference/imap/configure.xml diff -u phpdoc/en/reference/imap/configure.xml:1.3 phpdoc/en/reference/imap/configure.xml:1.4 --- phpdoc/en/reference/imap/configure.xml:1.3 Mon Jan 20 15:21:40 2003 +++ phpdoc/en/reference/imap/configure.xml Mon Jan 20 16:41:12 2003 @@ -1,11 +1,14 @@ - + &reftitle.install; To get these functions to work, you have to compile PHP with --with-imap[=DIR], where DIR is the - c-client install prefix. + c-client install prefix. From our example above, you would use + --with-imap=/usr/local/imap-2000b. This location + depends on where you created this directory according to the + description above. -- 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=20663&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/errorfunc/functions trigger-error.xml
pollita Mon Jan 20 15:46:26 2003 EDT Modified files: /phpdoc/en/reference/errorfunc/functionstrigger-error.xml Log: Bug # 20663 + Minor WS fixes. Index: phpdoc/en/reference/errorfunc/functions/trigger-error.xml diff -u phpdoc/en/reference/errorfunc/functions/trigger-error.xml:1.2 phpdoc/en/reference/errorfunc/functions/trigger-error.xml:1.3 --- phpdoc/en/reference/errorfunc/functions/trigger-error.xml:1.2 Wed Apr 17 02:37:46 2002 +++ phpdoc/en/reference/errorfunc/functions/trigger-error.xml Mon Jan 20 15:46:25 +2003 @@ -1,5 +1,5 @@ - + @@ -35,9 +35,15 @@ - - See set_error_handler for a more extensive example. - + + See set_error_handler for a more extensive example. + + + + + error_msg is limited to 1024 characters in length. + Any additional characters beyond 1024 will be truncated. + -- 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:
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
Previous Comments:
[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=20663&edit=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=20663&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/imap configure.xml /en/reference/recode configure.xml /en/reference/yaz configure.xml
philip Mon Jan 20 15:21:42 2003 EDT Modified files: /phpdoc/en/reference/imap configure.xml /phpdoc/en/reference/recode configure.xml /phpdoc/en/reference/yazconfigure.xml Log: Implement warn.imaprecodeyaz; which states imap cannot be compiled with either yaz or recode. Index: phpdoc/en/reference/imap/configure.xml diff -u phpdoc/en/reference/imap/configure.xml:1.2 phpdoc/en/reference/imap/configure.xml:1.3 --- phpdoc/en/reference/imap/configure.xml:1.2 Fri Jan 10 20:15:32 2003 +++ phpdoc/en/reference/imap/configure.xml Mon Jan 20 15:21:40 2003 @@ -1,5 +1,5 @@ - + &reftitle.install; @@ -15,6 +15,9 @@ into the PHP configure line. + + &warn.imaprecodeyaz; + + &reftitle.install; @@ -21,6 +21,9 @@ their own hash_insert function. + + &warn.imaprecodeyaz; + + &reftitle.install; @@ -26,6 +26,9 @@ + + &warn.imaprecodeyaz; +
[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=19959&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en language-snippets.ent
philip Mon Jan 20 15:18:54 2003 EDT Modified files: /phpdoc/en language-snippets.ent Log: Expand the newly created &warn.imaprecodeyaz; Index: phpdoc/en/language-snippets.ent diff -u phpdoc/en/language-snippets.ent:1.37 phpdoc/en/language-snippets.ent:1.38 --- phpdoc/en/language-snippets.ent:1.37Mon Jan 20 15:01:32 2003 +++ phpdoc/en/language-snippets.ent Mon Jan 20 15:18:54 2003 @@ -1,4 +1,4 @@ - + This extension is EXPERIMENTAL. The behaviour of this extension -- @@ -46,9 +46,11 @@ operator for testing the return value of this function.'> -The IMAP extension -cannot be used in conjuction with the recode -or YAZ extensions.'> +The IMAP extension cannot be used in conjuction with +the recode or YAZ extensions. This is due to the fact that they +both share the same internal symbol.'> This function -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/filesystem/functions fgetc.xml
pollita Mon Jan 20 15:18:50 2003 EDT Modified files: /phpdoc/en/reference/filesystem/functions fgetc.xml Log: Bug # 19959. fgetc() :: binary safe. Index: phpdoc/en/reference/filesystem/functions/fgetc.xml diff -u phpdoc/en/reference/filesystem/functions/fgetc.xml:1.5 phpdoc/en/reference/filesystem/functions/fgetc.xml:1.6 --- phpdoc/en/reference/filesystem/functions/fgetc.xml:1.5 Wed Jan 15 15:22:10 2003 +++ phpdoc/en/reference/filesystem/functions/fgetc.xml Mon Jan 20 15:18:50 2003 @@ -1,5 +1,5 @@ - + @@ -21,6 +21,13 @@ The file pointer must be valid, and must point to a file successfully opened by fopen, popen, or fsockopen. + + + + + This function is binary safe. + + See also fread, fopen, -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21244 [Com]: Information about placing php.ini not accurate
ID: 21244 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.3.0 New Comment: When running multiple php installations with the php.ini file located in each install directory you must be sure to remove any path's from the system enviroment variables (Win). Otherwise you may find one installation trying to access anothers extensions etc., even if they are correctly declared in the individual .ini files. Glen Previous Comments: [2002-12-28 07:54:16] [EMAIL PROTECTED] The documenation states in http://www.php.net/manual/en/install.windows.php about php.ini location on Windows: Copy your chosen ini file (see below) to your '%WINDOWS%' directory on Windows 9x/Me or to your '%SYSTEMROOT%' directory under Windows NT/2000/XP and rename it to php.ini. Your '%WINDOWS%' or '%SYSTEMROOT%' directory is typically: [...] However, php.ini can also be placed in to the directory where php is installed. This is more error save, because one does never have an old php.ini file dumpling in the windows directory. Additionally it's possible to run multiple php installations with different ini settings on the same system if php.ini is placed in the php binary directory. On the same page the list of php extensions is rather outdated. Some extensions from php3 are still there, some others are missing... I can try to compile a list as of 4.3.0 if you like. Christoph -- Edit this bug report at http://bugs.php.net/?id=21244&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en language-snippets.ent
philip Mon Jan 20 15:01:36 2003 EDT Modified files: /phpdoc/en language-snippets.ent Log: Adding IMAP warning, regarding YAZ and recode. (warn.imaprecodeyaz) Index: phpdoc/en/language-snippets.ent diff -u phpdoc/en/language-snippets.ent:1.36 phpdoc/en/language-snippets.ent:1.37 --- phpdoc/en/language-snippets.ent:1.36Wed Jan 15 06:50:59 2003 +++ phpdoc/en/language-snippets.ent Mon Jan 20 15:01:32 2003 @@ -1,4 +1,4 @@ - + This extension is EXPERIMENTAL. The behaviour of this extension -- @@ -45,6 +45,10 @@ information. Use the === operator for testing the return value of this function.'> + +The IMAP extension +cannot be used in conjuction with the recode +or YAZ extensions.'> This function -- 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=18705&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/strings/functions strstr.xml
pollita Mon Jan 20 14:59:29 2003 EDT Modified files: /phpdoc/en/reference/strings/functions strstr.xml Log: Bug # 18705. Encourage use of strpos over strstr when only verifying existence of needle in haystack. Index: phpdoc/en/reference/strings/functions/strstr.xml diff -u phpdoc/en/reference/strings/functions/strstr.xml:1.2 phpdoc/en/reference/strings/functions/strstr.xml:1.3 --- phpdoc/en/reference/strings/functions/strstr.xml:1.2Wed Apr 17 02:44:23 2002 +++ phpdoc/en/reference/strings/functions/strstr.xmlMon Jan 20 14:59:29 2003 @@ -1,5 +1,5 @@ - + @@ -42,6 +42,15 @@ ]]> + + + + + If you only want to determine if a particular needle + occours within haystack, use the faster and less memory + intensive function strpos instead. + + See also ereg, preg_match, -- 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 :{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=15166&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/pcre/functions preg-replace.xml
pollita Mon Jan 20 14:52:12 2003 EDT
Modified files:
/phpdoc/en/reference/pcre/functions preg-replace.xml
Log:
Bug # 15166. Backreferences followed by numeric literals.
Index: phpdoc/en/reference/pcre/functions/preg-replace.xml
diff -u phpdoc/en/reference/pcre/functions/preg-replace.xml:1.3
phpdoc/en/reference/pcre/functions/preg-replace.xml:1.4
--- phpdoc/en/reference/pcre/functions/preg-replace.xml:1.3 Tue Jul 23 18:04:54
2002
+++ phpdoc/en/reference/pcre/functions/preg-replace.xml Mon Jan 20 14:52:12 2003
@@ -1,5 +1,5 @@
-
+
@@ -34,6 +34,40 @@
\\0 or $0 refers to the text matched
by the whole pattern. Opening parentheses are counted from left to right
(starting from 1) to obtain the number of the capturing subpattern.
+
+
+ When working with a replacement pattern where a backreference is immediately
+ followed by another number (i.e.: placing a literal number immediately
+ after a matched pattern), you cannot use the familiar \\1
+ notation for your backreference. \\11, for example,
+ would confuse preg_replace since it does not know whether
+ you want the \\1 backreference followed by a literal
+1,
+ or the \\11 backreference followed nothing. In this case
+ the solution is to use \${1}1. This creates an
+ isolated $1 backreference, leaving the 1
+ as a literal.
+
+
+
+ Using backreferences followed by numeric literals.
+
+
+
+
If matches are found, the new subject will
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21774 [Opn]: Chokes on php_version.h during configure
ID: 21774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: *Compile Issues +Bug Type: Documentation problem Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: It is a known issue that using non-gnu utilities may cause PHP install not to work. This should be documented. Previous Comments: [2003-01-20 10:25:30] [EMAIL PROTECTED] I've had problems with compiling php 4.3 on 4 different solaris 8 machines. Last thing you can see on the screen is 'Updated php_version.h'. At this point it just hangs, System load goes up to 1.00. A list of processes show a high cpu usage on 'tr'. ps looks like admin 26932 77.3 0.1 928 528 pts/2R 11:13:46 0:31 tr x- x_ top looks like 26932 admin1 00 928K 528K run 1:02 93.78% tr Solution. I was to install the GNU Textutils http://www.gnu.org/directory/textutils.html Works perfect. Figured this may help other users if the same problem occures -- Edit this bug report at http://bugs.php.net/?id=21774&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/http/functions setcookie.xml
philip Mon Jan 20 13:46:37 2003 EDT Modified files: /phpdoc/en/reference/http/functions setcookie.xml Log: Move the delete information after the view. set -> view -> delete. Index: phpdoc/en/reference/http/functions/setcookie.xml diff -u phpdoc/en/reference/http/functions/setcookie.xml:1.13 phpdoc/en/reference/http/functions/setcookie.xml:1.14 --- phpdoc/en/reference/http/functions/setcookie.xml:1.13 Mon Jan 20 13:43:40 2003 +++ phpdoc/en/reference/http/functions/setcookie.xmlMon Jan 20 13:46:35 2003 @@ -1,5 +1,5 @@ - + @@ -107,23 +107,6 @@ - When deleting a cookie you should assure that the expiration date - is in the past, to trigger the removal mechanism in your browser. - Examples follow how to delete cookies sent in previous example: - - setcookie delete examples - - - - - - Note that the value portion of the cookie will automatically be urlencoded when you send the cookie, and when it is received, it is automatically decoded and assigned to a variable by the same @@ -143,6 +126,23 @@ ]]> + + + When deleting a cookie you should assure that the expiration date + is in the past, to trigger the removal mechanism in your browser. + Examples follow how to delete cookies sent in previous example: + + setcookie delete examples + + + + You may also set array cookies by using array notation in the -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/reference/http/functions setcookie.xml
philip Mon Jan 20 13:43:41 2003 EDT Modified files: /phpdoc/en/reference/http/functions setcookie.xml Log: Expand the examples a little, also not rely on register_globals. Index: phpdoc/en/reference/http/functions/setcookie.xml diff -u phpdoc/en/reference/http/functions/setcookie.xml:1.12 phpdoc/en/reference/http/functions/setcookie.xml:1.13 --- phpdoc/en/reference/http/functions/setcookie.xml:1.12 Wed Nov 6 23:59:54 2002 +++ phpdoc/en/reference/http/functions/setcookie.xmlMon Jan 20 13:43:40 2003 @@ -1,5 +1,5 @@ - + @@ -95,9 +95,13 @@ setcookie send examples @@ -110,9 +114,11 @@ setcookie delete examples @@ -126,8 +132,14 @@ @@ -141,14 +153,27 @@ -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] cvs: phpdoc /en/chapters install.omnihttpd.xmlinstall.xitami.xml
Tell omnihttpd and xitami users that they need cgi.force_redirect = 0 too. This is related to bug #16111 It would be nice to add this in a separate XML file, or as a snippet, or something, not copied several times. What if someone modifies a few words (ie. typofix). Then he needs to find out where this thing is copied... Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/chapters install.iis.xml install.omnihttpd.xml install.xitami.xml
philip Mon Jan 20 13:11:53 2003 EDT Modified files: /phpdoc/en/chapters install.omnihttpd.xml install.iis.xml install.xitami.xml Log: Implement solution to bug #16111 into a couple faqs. Index: phpdoc/en/chapters/install.omnihttpd.xml diff -u phpdoc/en/chapters/install.omnihttpd.xml:1.3 phpdoc/en/chapters/install.omnihttpd.xml:1.4 --- phpdoc/en/chapters/install.omnihttpd.xml:1.3Mon Jan 20 02:24:59 2003 +++ phpdoc/en/chapters/install.omnihttpd.xmlMon Jan 20 13:11:52 2003 @@ -1,5 +1,5 @@ - + Servers-OmniHTTPd Server @@ -18,22 +18,9 @@ Important for CGI users - When running PHP as CGI with IIS, PWS, OmniHTTPD or Xitami, - you MUST set the - cgi.force_redirect directive to 0. - It defaults to 1 so be sure the directive - isn't commented out (with a ;). - - - It's important that you're 100% sure that &php.ini; is - being read by PHP. To test this, make a call to - phpinfo and near the top will be a - listing called Configuration File (php.ini). - This will tell you where PHP is looking for &php.ini; and - whether or not it's being read. If just a PATH exists - than it's not being read and you should put your &php.ini; - there. If &php.ini; is included with the PATH than it is - being read. + Read the faq + on cgi.force_redirect for important details. This + directive needs to be set to 0. Index: phpdoc/en/chapters/install.iis.xml diff -u phpdoc/en/chapters/install.iis.xml:1.4 phpdoc/en/chapters/install.iis.xml:1.5 --- phpdoc/en/chapters/install.iis.xml:1.4 Mon Jan 20 02:12:46 2003 +++ phpdoc/en/chapters/install.iis.xml Mon Jan 20 13:11:52 2003 @@ -1,5 +1,5 @@ - + Servers-IIS/PWS @@ -13,22 +13,9 @@ Important for CGI users - When running PHP as CGI with IIS, PWS, OmniHTTPD or Xitami, - you MUST set the - cgi.force_redirect directive to 0. - It defaults to 1 so be sure the directive - isn't commented out (with a ;). - - - It's important that you're 100% sure that &php.ini; is - being read by PHP. To test this, make a call to - phpinfo and near the top will be a - listing called Configuration File (php.ini). - This will tell you where PHP is looking for &php.ini; and - whether or not it's being read. If just a PATH exists - than it's not being read and you should put your &php.ini; - there. If &php.ini; is included with the PATH than it is - being read. + Read the faq + on cgi.force_redirect for important details. This + directive needs to be set to 0. Index: phpdoc/en/chapters/install.xitami.xml diff -u phpdoc/en/chapters/install.xitami.xml:1.2 phpdoc/en/chapters/install.xitami.xml:1.3 --- phpdoc/en/chapters/install.xitami.xml:1.2 Mon Jan 20 02:24:59 2003 +++ phpdoc/en/chapters/install.xitami.xml Mon Jan 20 13:11:53 2003 @@ -1,5 +1,5 @@ - + Servers-Xitami @@ -16,22 +16,9 @@ Important for CGI users - When running PHP as CGI with IIS, PWS, OmniHTTPD or Xitami, - you MUST set the - cgi.force_redirect directive to 0. - It defaults to 1 so be sure the directive - isn't commented out (with a ;). - - - It's important that you're 100% sure that &php.ini; is - being read by PHP. To test this, make a call to - phpinfo and near the top will be a - listing called Configuration File (php.ini). - This will tell you where PHP is looking for &php.ini; and - whether or not it's being read. If just a PATH exists - than it's not being read and you should put your &php.ini; - there. If &php.ini; is included with the PATH than it is - being read. + Read the faq + on cgi.force_redirect for important details. This + directive needs to be set to 0. @@ -92,4 +79,4 @@ vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 ---> \ No newline at end of file +--> -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #17180 [Com]: Operator Precedence
ID: 17180 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type:Documentation problem PHP Version: 4.2.0 New Comment: There seems to be a more general principle at work here -- see, for example, related bug report 17386 (http://bugs.php.net/bug.php?id=17386). Would it be true to say something like: when an assignment operator occurs in a position where the usual rules of precedence would produce a parse error, the precedence of the assignment is artificially increased to allow the expression to parse; this usually gives the intended result. Cheers! Mike Previous Comments: [2003-01-18 16:14:46] [EMAIL PROTECTED] This has now been documented: http://cvs.php.net/cvs.php/phpdoc/en/language/operators.xml Thanks for the report :) [2002-05-16 13:27:03] [EMAIL PROTECTED] Marking this as a doc problem. [2002-05-14 13:46:58] [EMAIL PROTECTED] Actually this is a bug, since in PHP manual it's clearly stated that ! operator has a priority over = operator. > It makes no sense to assign anything to NOT(a variable), > so PHP takes care of that by > changing the precedence a little in this case. In other words - if user makes a mistake and writes illegal code, PHP takes care about that and makes this code work (but in a way different from what developer has expected). Also if you consider any other programming languages, if you write a code which should not compile by language specifications (like the above code in PHP), no compiler will try to "take care" of that. If you insist on that "care", then you definetely have to reflect that in the manual, otherwise it's nothing but a bug. [2002-05-13 18:30:31] [EMAIL PROTECTED] This behaviour is capable to confuse the developer and if this is "features" it must be documented in manual. [2002-05-13 18:20:14] [EMAIL PROTECTED] Well, but it's stupid to do something like that. It makes no sense to assign anything to NOT(a variable), so PHP takes care of that by changing the precedence a little in this case. 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/17180 -- Edit this bug report at http://bugs.php.net/?id=17180&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] #18403 [Opn->Fbk]: changable directive information(ini_set)
Writing this "off-bug-system", as my comments are not really related to the bug itself... I have just commited the script: phpdoc/scripts/genPHP_INI_ENTRY.php which should replace my aging phpdoc/scripts/mk_ini_set_table.sh Test that script. By default it will generate files named 'test_ini.xml' in the appropriate dirs. If all looks OK, we can go ahead and remove the ini_set table, make the new script generate all the ini.xml files and change the manual files where appropriate (makefile, etc.) Well, then it will going to be a php.in and it's detection code will be removed I guess, as the PHP source path, and the phpdoc source path is already known after ./configure, so there is no need to complicate things with using another detection algorithm.. Also, look at the approach there. It might be useful for making replacements for the funcsummary and funclist scripts. Well, as we talked about this in the past, those files are not used at all, they are just exist... Maybe some script uses one of them, I cannot remember, but actually they have no use. We talked at that particular March PHP meeting about having an XML format instead provided for download at php.net/download-docs for IDEs to use... I already have a method to generate that (using XSLT) so this would be the first thing to use xsltproc and not jade ;)) So it would also be nice to start experimenting with xslt without affecting the current system too much... Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21728 [Opn]: Additional (kindly weird example) for sort()
ID: 21728
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.4.0-dev
New Comment:
There was (and is) a suspicion in me about because the sort is made by
qsort algo. As you said all comparisons are valid ones but the order is
unpredicatble.
Thanks for the comment.
I think we should rethink the sort() function and maybe change the
default way of sorting (from SORT_REGULAR to SORT_STRING).
Previous Comments:
[2003-01-20 11:54:48] [EMAIL PROTECTED]
Well, one of the problems here is that some of the array elements will
take different values in an element-to-element comparison depending on
the type of the other element. For example, "true" will be just that
compared to another string, but 0 when compared against an integer;
strings and integers are both converted to Boolean when compared to
true/false (with resulting loss of significant information).
Another problem is that if you're using a non-sequential sorting
algorithm (such as shellsort or quicksort), simply changing the length
of the array will probably change which element is compared to which,
and hence, because of the strangeness of "dual values" caused by
type-juggling, the final order of the array. (This may be even worse
for an algorithm that is not guaranteed to maintain the order of equal
items.)
If you take a look at the sorted versions of each array cited, you will
find that all of the element-to-neighbour-element comparisons are
actually valid, thus:
array("a","b","c","d","4",5,4,"true","TRUE",true) --
true : 4 ==> (bool)true == true
4 : "4" ==> (int) 4 == 4
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : 5 ==> (int) 0 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c") --
false : "TRUE" ==> (bool) false < true
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "true" ==> (string) "a"< "true"
"true" : true==> (bool) true == true
true : "b" ==> (bool) true == true
"b": "c" ==> (string) "b"< "c"
"c": 4 ==> (int)0 == 4
4 : "4" ==> (int)4 == 4
"4": 5 ==> (int)4 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c", "d") --
false : "4" ==> (bool)false < true
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : true==> (bool)true == true
true : 4 ==> (bool)true == true
4 : 5 ==> (int) 4 < 5
So, in each case, we have a valid sort -- just a *different* valid
sort. The prime determiners here seem to be the non-sequential order
in which the individual comparisons are performed, and, as has been
indicated, the automatic casting that takes place for each one.
(Incidentally, whilst putting the above together I was unable to find a
definitive listing of *exactly* what automatic type-conversions take
place in which contexts. This is a definite oversight, as in contexts
like the above it's important to know, for example, that comparing an
int to a bool will cast the int to bool, and not the bool to int.
Perhaps this needs to become a doc problem for the inclusion of such a
list or table?)
Hope this enlightens at least some souls reading this far!
Cheers!
Mike
[2003-01-18 12:23:24] [EMAIL PROTECTED]
Maybe it should not happen but the as I said the comparisons done are
correct (extensive type juggling). Maybe SORT_REGULAR is not the way to
sort (by default) but SORT_STRING.
Comments from other people are welcome :)
[2003-01-18 12:17:00] [EMAIL PROTECTED]
I swear I get different results by just adding a "d" to the end. This
should not happen.
[2003-01-18 12:05:10] [EMAIL PROTECTED]
As I said this is very complicated case because of the type juggling.
I needed 30 minute to realize that 21444 is not a bug but a bogus (for
me and Derick). I agree that the result is weird. I modified the the
compare function to see what comparisons are made. All of them look
ok.
On my php I have the same results
[PHP-DOC] #21728 [Com]: Additional (kindly weird example) for sort()
ID: 21728
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: All
PHP Version: 4.4.0-dev
New Comment:
Well, one of the problems here is that some of the array elements will
take different values in an element-to-element comparison depending on
the type of the other element. For example, "true" will be just that
compared to another string, but 0 when compared against an integer;
strings and integers are both converted to Boolean when compared to
true/false (with resulting loss of significant information).
Another problem is that if you're using a non-sequential sorting
algorithm (such as shellsort or quicksort), simply changing the length
of the array will probably change which element is compared to which,
and hence, because of the strangeness of "dual values" caused by
type-juggling, the final order of the array. (This may be even worse
for an algorithm that is not guaranteed to maintain the order of equal
items.)
If you take a look at the sorted versions of each array cited, you will
find that all of the element-to-neighbour-element comparisons are
actually valid, thus:
array("a","b","c","d","4",5,4,"true","TRUE",true) --
true : 4 ==> (bool)true == true
4 : "4" ==> (int) 4 == 4
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : 5 ==> (int) 0 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c") --
false : "TRUE" ==> (bool) false < true
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "true" ==> (string) "a"< "true"
"true" : true==> (bool) true == true
true : "b" ==> (bool) true == true
"b": "c" ==> (string) "b"< "c"
"c": 4 ==> (int)0 == 4
4 : "4" ==> (int)4 == 4
"4": 5 ==> (int)4 < 5
array("a","b","4",5,4,"true","TRUE",true, false, "c", "d") --
false : "4" ==> (bool)false < true
"4": "TRUE" ==> (string) "4"< "TRUE"
"TRUE" : "a" ==> (string) "TRUE" < "a"
"a": "b" ==> (string) "a"< "b"
"b": "c" ==> (string) "b"< "c"
"c": "d" ==> (string) "c"< "d"
"d": "true" ==> (string) "d"< "true"
"true" : true==> (bool)true == true
true : 4 ==> (bool)true == true
4 : 5 ==> (int) 4 < 5
So, in each case, we have a valid sort -- just a *different* valid
sort. The prime determiners here seem to be the non-sequential order
in which the individual comparisons are performed, and, as has been
indicated, the automatic casting that takes place for each one.
(Incidentally, whilst putting the above together I was unable to find a
definitive listing of *exactly* what automatic type-conversions take
place in which contexts. This is a definite oversight, as in contexts
like the above it's important to know, for example, that comparing an
int to a bool will cast the int to bool, and not the bool to int.
Perhaps this needs to become a doc problem for the inclusion of such a
list or table?)
Hope this enlightens at least some souls reading this far!
Cheers!
Mike
Previous Comments:
[2003-01-18 12:23:24] [EMAIL PROTECTED]
Maybe it should not happen but the as I said the comparisons done are
correct (extensive type juggling). Maybe SORT_REGULAR is not the way to
sort (by default) but SORT_STRING.
Comments from other people are welcome :)
[2003-01-18 12:17:00] [EMAIL PROTECTED]
I swear I get different results by just adding a "d" to the end. This
should not happen.
[2003-01-18 12:05:10] [EMAIL PROTECTED]
As I said this is very complicated case because of the type juggling.
I needed 30 minute to realize that 21444 is not a bug but a bogus (for
me and Derick). I agree that the result is weird. I modified the the
compare function to see what comparisons are made. All of them look
ok.
On my php I have the same results on the script with "d" added at the
end. A little modification changes the order of comparisons and thus
the result is different. Maybe this is because the default sort type is
SORT_REGULAR. If SORT_STRING is used the result is expected. I think
that the case I provided is good to show the users that the results are
kinda unexpected when both the array contains values from various
datatypes and SORT_REGULAR is used. So if the
[PHP-DOC] cvs: phpdoc /en/faq installation.xml
philip Mon Jan 20 12:53:45 2003 EDT Modified files: /phpdoc/en/faq installation.xml Log: Be consistent and use installation. instead of install. Index: phpdoc/en/faq/installation.xml diff -u phpdoc/en/faq/installation.xml:1.18 phpdoc/en/faq/installation.xml:1.19 --- phpdoc/en/faq/installation.xml:1.18 Mon Jan 20 12:48:05 2003 +++ phpdoc/en/faq/installation.xml Mon Jan 20 12:53:44 2003 @@ -1,5 +1,5 @@ - + Installation Installation @@ -403,7 +403,7 @@ - + Windows: I've followed all the instructions, but still can't @@ -418,13 +418,13 @@ rights to php.exe. Also, any authenticated user will also need rights to execute php.exe. And for IIS4 you need to tell it that PHP is a script engine. - Also, you will want to read - this faq. + Also, you will want to read + this faq. - + When running PHP as CGI with IIS, PWS, OmniHTTPD or Xitami, @@ -443,13 +443,13 @@ Because the default is 1, it's critical that you're 100% sure that the correct &php.ini; file is being - read. Read this faq + read. Read this faq for details. - + How do I know if my &php.ini; is being found and read? It -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/faq installation.xml
philip Mon Jan 20 12:48:05 2003 EDT Modified files: /phpdoc/en/faq installation.xml Log: Implement solution to #16111 into a couple faqs. Index: phpdoc/en/faq/installation.xml diff -u phpdoc/en/faq/installation.xml:1.17 phpdoc/en/faq/installation.xml:1.18 --- phpdoc/en/faq/installation.xml:1.17 Mon Jun 10 06:22:39 2002 +++ phpdoc/en/faq/installation.xml Mon Jan 20 12:48:05 2003 @@ -1,5 +1,5 @@ - + Installation Installation @@ -418,6 +418,58 @@ rights to php.exe. Also, any authenticated user will also need rights to execute php.exe. And for IIS4 you need to tell it that PHP is a script engine. + Also, you will want to read + this faq. + + + + + + + + When running PHP as CGI with IIS, PWS, OmniHTTPD or Xitami, + I get the following error: Security Alert! PHP CGI + cannot be accessed directly.. + + + + + You must set the + cgi.force_redirect directive to 0. + It defaults to 1 so be sure the directive + isn't commented out (with a ;). Like + all directives, this is set in &php.ini; + + + Because the default is 1, it's critical + that you're 100% sure that the correct &php.ini; file is being + read. Read this faq + for details. + + + + + + + + How do I know if my &php.ini; is being found and read? It + seems like it isn't as my changes aren't being implemented. + + + + + To be sure your &php.ini; is being read by PHP, make a call to + phpinfo and near the top will be a + listing called Configuration File (php.ini). + This will tell you where PHP is looking for &php.ini; and + whether or not it's being read. If just a directory PATH exists + than it's not being read and you should put your &php.ini; + in that directory. If &php.ini; is included within the PATH than + it is being read. + + + If &php.ini; is being read and you're running PHP as a module + then be sure to restart PHP after making changes to &php.ini; -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] cvs: phpdoc /en/chapters install.omnihttpd.xmlinstall.xitami.xml
Tell omnihttpd and xitami users that they need cgi.force_redirect = 0 too. This is related to bug #16111 It would be nice to add this in a separate XML file, or as a snippet, or something, not copied several times. What if someone modifies a few words (ie. typofix). Then he needs to find out where this thing is copied... I thought about it but it's perfect so no need to fix it :) It's such a special case that I didn't think it deserves a snippet. Although one idea is to put it in a faq and refer to it, that might be a good idea. Yes. +1 Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21770 [Opn->Csd]: typo at migration4.empty
ID: 21770 Updated by: [EMAIL PROTECTED] -Summary: [chm] bug on migration4.empty.html Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: windows PHP Version: 4.3.0 New Comment: The documentation has been updated: http://cvs.php.net/cvs.php/phpdoc/en/appendices/migration4.xml Thanks for the report :) Previous Comments: [2003-01-20 06:01:15] [EMAIL PROTECTED] I have found a bug on page migration4.empty.html [chm date: 2002-12-27]... This new behavior makes sense in web applications, with all input fields returning strings even if numeric input is requested, and with PHP's capabilities of automatic type conversion. But on the ""other had" other hand it might break your code in a rather subtle way, leading to misbehavior that is hard to track down if you do not know about what to look for. -- Edit this bug report at http://bugs.php.net/?id=21770&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /en/appendices migration4.xml
philip Mon Jan 20 11:07:36 2003 EDT Modified files: /phpdoc/en/appendices migration4.xml Log: Typo, closes bug #21770 Index: phpdoc/en/appendices/migration4.xml diff -u phpdoc/en/appendices/migration4.xml:1.27 phpdoc/en/appendices/migration4.xml:1.28 --- phpdoc/en/appendices/migration4.xml:1.27Wed Nov 20 08:11:20 2002 +++ phpdoc/en/appendices/migration4.xml Mon Jan 20 11:07:35 2003 @@ -1,5 +1,5 @@ - + Migrating from PHP 3 to PHP 4 @@ -312,7 +312,7 @@ This new behavior makes sense in web applications, with all input fields returning strings even if numeric input is requested, and with PHP's capabilities of automatic type conversion. But on the -other had it might break your code in a rather subtle way, +other hand it might break your code in a rather subtle way, leading to misbehavior that is hard to track down if you do not know about what to look for. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] cvs: phpdoc /en/chapters install.omnihttpd.xmlinstall.xitami.xml
On Mon, 20 Jan 2003, Gabor Hojtsy wrote: > > Tell omnihttpd and xitami users that they need cgi.force_redirect = 0 too. > > This is related to bug #16111 > > It would be nice to add this in a separate XML file, or as a snippet, or > something, not copied several times. What if someone modifies a few > words (ie. typofix). Then he needs to find out where this thing is copied... I thought about it but it's perfect so no need to fix it :) It's such a special case that I didn't think it deserves a snippet. Although one idea is to put it in a faq and refer to it, that might be a good idea. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21770 [NEW]: [chm] bug on migration4.empty.html
From: [EMAIL PROTECTED] Operating system: windows PHP version: 4.3.0 PHP Bug Type: Documentation problem Bug description: [chm] bug on migration4.empty.html I have found a bug on page migration4.empty.html [chm date: 2002-12-27]... This new behavior makes sense in web applications, with all input fields returning strings even if numeric input is requested, and with PHP's capabilities of automatic type conversion. But on the ""other had" other hand it might break your code in a rather subtle way, leading to misbehavior that is hard to track down if you do not know about what to look for. -- Edit bug report at http://bugs.php.net/?id=21770&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21770&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21770&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21770&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21770&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21770&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21770&r=support Expected behavior: http://bugs.php.net/fix.php?id=21770&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21770&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21770&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21770&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21770&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21770&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21770&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21770&r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /xsl version.xml
hholzgraMon Jan 20 05:58:29 2003 EDT Modified files: /phpdoc/xsl version.xml Log: latest CVS is now PHP 5 Index: phpdoc/xsl/version.xml diff -u phpdoc/xsl/version.xml:1.9 phpdoc/xsl/version.xml:1.10 --- phpdoc/xsl/version.xml:1.9 Wed Jan 8 06:57:43 2003 +++ phpdoc/xsl/version.xml Mon Jan 20 05:58:29 2003 @@ -85,13 +85,13 @@ - + - - - - + + + + @@ -1416,7 +1416,7 @@ - + @@ -1427,14 +1427,15 @@ - - + + + @@ -1467,7 +1468,7 @@ - + @@ -1519,16 +1520,16 @@ - - - - - - - - - - + + + + + + + + + + @@ -1564,14 +1565,14 @@ - - - - - - - - + + + + + + + + @@ -1664,7 +1665,7 @@ - + @@ -1680,9 +1681,9 @@ - - - + + + @@ -1762,16 +1763,16 @@ - - - - - - - - - - + + + + + + + + + + @@ -1864,6 +1865,7 @@ + @@ -2005,16 +2007,16 @@ - - + + - - - - + + + + - + @@ -2034,12 +2036,12 @@ - + - + @@ -2089,7 +2091,7 @@ - + @@ -2106,7 +2108,7 @@ - + @@ -2328,6 +2330,7 @@ + @@ -2348,6 +2351,7 @@ + @@ -2356,6 +2360,7 @@ + @@ -2376,6 +2381,7 @@ + @@ -2612,7 +2618,7 @@ - + @@ -2634,8 +2640,8 @@ - - + + @@ -2681,7 +2687,7 @@ - + @@ -2841,6 +2847,7 @@ + @@ -2880,6 +2887,7 @@ + @@ -2945,6 +2953,7 @@ + @@ -2972,15 +2981,15 @@ - - - - - - - - - + + + + + + + + + @@ -3045,10 +3054,10 @@ - + - - + + @@ -3173,19 +3182,20 @@ - + - + + @@ -3238,7 +3248,7 @@ - + @@ -3277,6 +3287,7 @@ + @@ -3286,6 +3297,7 @@ + @@ -3295,6 +3307,7 @@ + -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] cvs: phpdoc /dsssl version.dsl
hholzgraMon Jan 20 05:58:15 2003 EDT Modified files: /phpdoc/dsssl version.dsl Log: latest CVS is now PHP 5 Index: phpdoc/dsssl/version.dsl diff -u phpdoc/dsssl/version.dsl:1.12 phpdoc/dsssl/version.dsl:1.13 --- phpdoc/dsssl/version.dsl:1.12 Thu Jan 9 08:11:00 2003 +++ phpdoc/dsssl/version.dslMon Jan 20 05:58:14 2003 @@ -145,13 +145,13 @@ ((equal-ci? (data nl) "clearstatcache") (literal "PHP 3, PHP 4 ")) ((equal-ci? (data nl) "closedir") (literal "PHP 3, PHP 4 ")) ((equal-ci? (data nl) "closelog") (literal "PHP 3, PHP 4 ")) - ((equal-ci? (data nl) "com_get") (literal "PHP 3>= 3.0.3, PHP 4 >= 4.0.5")) + ((equal-ci? (data nl) "com_get") (literal "PHP 3>= 3.0.3, 4.0.5 - 4.3.0 only")) ((equal-ci? (data nl) "com_invoke") (literal "PHP 3>= 3.0.3")) ((equal-ci? (data nl) "com_load") (literal "PHP 3>= 3.0.3")) - ((equal-ci? (data nl) "com_propget") (literal "PHP 3>= 3.0.3, PHP 4 >= 4.0.5")) - ((equal-ci? (data nl) "com_propput") (literal "PHP 3>= 3.0.3, PHP 4 >= 4.0.5")) - ((equal-ci? (data nl) "com_propset") (literal "PHP 3>= 3.0.3, PHP 4 >= 4.0.5")) - ((equal-ci? (data nl) "com_set") (literal "PHP 3>= 3.0.3, PHP 4 >= 4.0.5")) + ((equal-ci? (data nl) "com_propget") (literal "PHP 3>= 3.0.3, 4.0.5 - 4.3.0 only")) + ((equal-ci? (data nl) "com_propput") (literal "PHP 3>= 3.0.3, 4.0.5 - 4.3.0 only")) + ((equal-ci? (data nl) "com_propset") (literal "PHP 3>= 3.0.3, 4.0.5 - 4.3.0 only")) + ((equal-ci? (data nl) "com_set") (literal "PHP 3>= 3.0.3, 4.0.5 - 4.3.0 only")) ((equal-ci? (data nl) "connection_aborted") (literal "PHP 3>= 3.0.7, PHP 4 ")) ((equal-ci? (data nl) "connection_status") (literal "PHP 3>= 3.0.7, PHP 4 ")) ((equal-ci? (data nl) "connection_timeout") (literal "PHP 3>= 3.0.7, PHP 4 <= 4.0.4")) @@ -1476,7 +1476,7 @@ ((equal-ci? (data nl) "addstring") (literal "PHP 4 >= 4.0.5")) ((equal-ci? (data nl) "add_iovec") (literal "4.0.2 - 4.0.6 only")) ((equal-ci? (data nl) "aggregate") (literal "PHP 4 >= 4.2.0")) - ((equal-ci? (data nl) "aggregate_info") (literal "PHP 4 CVS only")) + ((equal-ci? (data nl) "aggregate_info") (literal "PHP 5 CVS only")) ((equal-ci? (data nl) "aggregate_methods") (literal "PHP 4 >= 4.2.0")) ((equal-ci? (data nl) "aggregate_methods_by_list") (literal "PHP 4 >= 4.2.0")) ((equal-ci? (data nl) "aggregate_methods_by_regexp") (literal "PHP 4 >= 4.2.0")) @@ -1487,14 +1487,15 @@ ((equal-ci? (data nl) "align") (literal "PHP 4 >= 4.0.5")) ((equal-ci? (data nl) "apache_child_terminate") (literal "PHP 4 >= 4.0.5")) ((equal-ci? (data nl) "apache_getenv") (literal "PHP 4 >= 4.3.0")) - ((equal-ci? (data nl) "apache_get_modules") (literal "PHP 4 CVS only")) - ((equal-ci? (data nl) "apache_get_version") (literal "PHP 4 CVS only")) + ((equal-ci? (data nl) "apache_get_modules") (literal "PHP 5 CVS only")) + ((equal-ci? (data nl) "apache_get_version") (literal "PHP 5 CVS only")) ((equal-ci? (data nl) "apache_request_headers") (literal "PHP 4 >= 4.3.0")) ((equal-ci? (data nl) "apache_response_headers") (literal "PHP 4 >= 4.3.0")) ((equal-ci? (data nl) "apache_setenv") (literal "PHP 4 >= 4.2.0")) ((equal-ci? (data nl) "apache_sub_req") (literal "4.0.4 - 4.1.2 only")) ((equal-ci? (data nl) "array_change_key_case") (literal "PHP 4 >= 4.2.0")) ((equal-ci? (data nl) "array_chunk") (literal "PHP 4 >= 4.2.0")) + ((equal-ci? (data nl) "array_combine") (literal "PHP 5 CVS only")) ((equal-ci? (data nl) "array_count_values") (literal "PHP 4 ")) ((equal-ci? (data nl) "array_diff") (literal "PHP 4 >= 4.0.1")) ((equal-ci? (data nl) "array_diff_assoc") (literal "PHP 4 >= 4.3.0")) @@ -1527,7 +1528,7 @@ ((equal-ci? (data nl) "assert") (literal "PHP 4 ")) ((equal-ci? (data nl) "assert_options") (literal "PHP 4 ")) ((equal-ci? (data nl) "atanh") (literal "PHP 4 >= 4.1.0")) - ((equal-ci? (data nl) "bcpowmod") (literal "PHP 4 CVS only")) + ((equal-ci? (data nl) "bcpowmod") (literal "PHP 5 CVS only")) ((equal-ci? (data nl) "bind") (literal "4.0.2 - 4.0.6 only")) ((equal-ci? (data nl) "bind_textdomain_codeset") (literal "PHP 4 >= 4.2.0")) ((equal-ci? (data nl) "birdstep_autocommit") (literal "PHP 4 >= 4.2.0")) @@ -1579,16 +1580,16 @@ ((equal-ci? (data nl) "class_exists") (literal "PHP 4 ")) ((equal-ci? (data nl) "close") (literal "4.0.2 - 4.0.6 only")) ((equal-ci? (data nl) "compact") (literal "PHP 4 ")) - ((equal-ci? (data nl) "com_addref") (literal "PHP 4 >= 4.1.0")) - ((equal-ci? (data nl) "com_event_sink") (literal "PHP 4 >= 4.2.3")) - ((equal-ci? (data nl) "COM_invoke") (literal "PHP 4 >= 4.0.5")) - ((equal-ci? (data nl) "com_invoke_ex") (literal "PHP 4 >= 4.3.0")) - ((equal-ci? (data nl) "com_isenum") (literal "PHP 4 >= 4.1.0")) - ((equal-ci? (data nl) "COM_load") (literal "PHP 4 >= 4.0.5")) - ((equal-ci? (data nl) "com_load_typelib") (literal "PHP 4 >= 4.1.0")) -
[PHP-DOC] JOIN for FREE ... Learn and Earn
Hello: My name is Charles Cedeno. I am now focusing in one online opportunity.I have tried several of these opportunities full of hype promising us thousands of dollars every month. I would get all excited and run to my family and friends with another "Great Money Maker ". It is a sad fact that many people who are in need of additional income, are being victimized by these fly by night scam artists. As a result of trying all these opportunities, I finally found the company which is true to their words. Not full of hype, but consistently send me the monthly check. They have given me the best compensation plan with their high % commission. I didn't have to perform some juggling act to maintain some 60 to 40% balance in my legs. It is not a pyramid, so there are no legs. It is not one of those binary compensation plan failures either. Everyone earns commissions here. They are providing a real service not the one that simply transfers wealth from the new signups to the people at the top. When you join, you will have a team of up line sponsors who will help you succeed every step of the way. Instead of being left alone, you will be guided step by step by real people, not those auto responders. Only you can make your own success together with the help of your sponsors. If you have 2 to 3 hours a day, you will be able to earn a full income in a few months. And there is absolutely no limit as to how much you can earn. It is designed to gain momentum after some time. But I prefer to avoid such statements as "You will get rich". I read it everywhere and will not allow myself to sound like them. I experienced it personally, you can be comfortable. To get your FREE membership ID, send email to [EMAIL PROTECTED] and put "REGISTER ME FOR FREE" in the subject and your full name in the body of your email. Also include the statement below in the body of your email. "By submitting a request for a FREE DHS Club membership I agree to receive emails from DHS Club for both their Consumer and Business Opportunities." I will then register you into the system. You will receive a confirmation email asking you to verify. Open it up and activate your free membership immediately. Then set back and watch as your new business explodes. Best regards, Charles Cedeno Note: You don't need to request for removal. This is a one-time email. Your email address will be automatically de-activated in our list if you don't respond to this mail. -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
