Re: [PHP-DOC] Someone that can help w/ our XSLT stylesheets
On Mon, 3 Feb 2003, Jesus M. Castagnetto wrote: > I attended Doug Tidwell's talk on "XSLT for > Bioinformatics" today, and he really knows his XSLT > quite well. Talked to him about the XSLT stylesheets > we are using for PHPDOC, and being that he has written > his book using DocBook, he was amenable to give us a > hand w/ getting them in working condition to > (eventually) replace the DSSSL ones we are currently > using. > > Doug also showed some really cool PDF generation using > Apache's FOP. So that would be another issue that > could be solved, because currently the XML -> PDF is > broken (due to the gigantic size of the PHP manual ;-) > > I am cc'ing him in this message, and hopefully the > DSSSL/XSLT gurus in the PHPDOC team could get in touch > with Doug and see what can be done. He has the > expertise, the desire and the availability. I added the unofficial official manual generation gurus to the cc list. See also: http://cvs.php.net/co.php/phpdoc/RFC/pdf_problems Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Someone that can help w/ our XSLT stylesheets
On Mon, 3 Feb 2003 17:11:47 -0800 (PST) "Jesus M. Castagnetto" <[EMAIL PROTECTED]> wrote: > Doug also showed some really cool PDF generation using > Apache's FOP. So that would be another issue that > could be solved, because currently the XML -> PDF is > broken (due to the gigantic size of the PHP manual ;-) I am not a DSSSL/XSLT guru at all, but I must admit that apache's FOP is definitely the greatest way for dumping the PDF files. We use it here at work with awesome results! Would be really nice to have it for PHP Manual too. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....] (fwd)
oh, I noticed :) Update: for now I only composed the script (partially based on Jesus's and Brad's code) that scans the the C sources and funcsummary.txt to a structured array of data. This, would then be compared to the XML in the docs and the C sources to get the actual parameter counts, return types and proto definitions. Comparing the two, you get some very interesting results. This script cannot be precise as the C code is a lot tricky and i am not going to write a C parser here. At most, it catched some 60-70% of the C sources. But so far, in just a few hours stubbing the code, I noticed how many inconsistencies were there. Let's see what Ilia is playing with. If same thing then we might want to merge the efforts somehow, otherwise I can commit my file once I make it be something more finalized and useful. -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 3 Feb 2003 18:00:15 + (GMT) Philip Olson <[EMAIL PROTECTED]> wrote: > Sorry, I wrote a wrong address for Ilia so here's a > correct one. > > Philip > > > -- Forwarded message -- > Date: Mon, 3 Feb 2003 17:46:08 + (GMT) > From: Philip Olson <[EMAIL PROTECTED]> > To: Maxim Maletsky <[EMAIL PROTECTED]> > Cc: Friedhelm Betz <[EMAIL PROTECTED]>, Gabor Hojtsy <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], [EMAIL PROTECTED] > Subject: Re: [PHP-DOC] proto-skript [was authors] > > On Mon, 3 Feb 2003, Maxim Maletsky wrote: > > Thanks, I think this can be useful to me. > > > > Actually, in base of this (and others out there) script(s), I am going > > to attempt creating a script that parses both the C code and the docs > > tree to look for any inconsistencies. > > > > Somewhat like a doc-bug hunter. The goal in this case will be to > > analyze the current documentation and get listed the functions that do > > not correspond to the current documentation, such as in our case some > > return values and parameter counts. Would be helpful getting a > > machine-generated summary of incorrectly documented protos and functions > > (like for things that have been changed since they were documented etc). > > > > I already saw things doing similar to that, so I've got the base. > > > > Any thoughts/complains/suggestions? If what comes out will work well for > > me and nobody objects, I will then commit it to the /phpdoc/scripts. > > Ilia has already created something that does this and > he's been going through it doing minor tweaks here and > there for awhile now. You may want to talk to him. > > Regards, > Philip > > > > > > > Friedhelm Betz <[EMAIL PROTECTED]> wrote... : > > > > > > > I have heard some rumors about someone creating a proto check script to > > > > > check whether the protos in phpdoc reflect the current protos of > > > > > functions in the php source. Take in account undocumented new > > > > > parameters, etc. too... I don't think that anybody can get on this to do > > > > > it manually in any reasonable time... > > > > > > > > Would be nice to investigate on this deeper and see whether we can do > > > > something about it. I could go ahead to write a similar script myself. > > > > > > Take a look at /phpdoc/scripts/xml_proto.php > > > never tried, but may be a good starting point. > > > > > > Friedhelm > > > > > > > > > -- > > > PHP Documentation Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > -- > > PHP Documentation Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] Someone that can help w/ our XSLT stylesheets
I attended Doug Tidwell's talk on "XSLT for Bioinformatics" today, and he really knows his XSLT quite well. Talked to him about the XSLT stylesheets we are using for PHPDOC, and being that he has written his book using DocBook, he was amenable to give us a hand w/ getting them in working condition to (eventually) replace the DSSSL ones we are currently using. Doug also showed some really cool PDF generation using Apache's FOP. So that would be another issue that could be solved, because currently the XML -> PDF is broken (due to the gigantic size of the PHP manual ;-) . I am cc'ing him in this message, and hopefully the DSSSL/XSLT gurus in the PHPDOC team could get in touch with Doug and see what can be done. He has the expertise, the desire and the availability. FYI, you can see the talk I mention (and others) at: http://www.ibm.com/developerworks/speakers/dtidwell -- Jesus "the Matchmaker" Castagnetto __ 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
Re: [PHP-DOC] preg_replace() docs need expliot warning
To follow up on James's note for whom wasn't reading today's short
conversation:
This topic popped up today as the security issue and ended up being
rather a missing warning in the documentation.
The two functions eval() and preg_replace() (when used with /e modifier)
evaluate strings as native PHP code. In some cases, string can be
composed with the user input, which, as James notes, is often the case with
preg_replace.
Problem I see (and Derick agreed) is that, the security of use for these
two functions are left up to the programmer's responsibility. And, many
PHP newcomers adore such "magic" functions as eval (along with variable
variables etc) and might carelessly misuse them.
The documentation for eval and preg_replace (with /e modifier) should
have a warning message advising to be very careful in mixing the
evaluation of the user input of any kind.
I guess we should add the warning ENTITY to language-snippets.en and
point that to the docs. Not sure yet about the most correct way of
describing this warning. Anyone?
--
Maxim Maletsky
[EMAIL PROTECTED]
On Mon, 3 Feb 2003 14:31:18 -0500 (EST) "James E. Flemer" <[EMAIL PROTECTED]> wrote:
> A warning about preg_replace() command needs to be added to
> the docs page for this command. The preg_replace() command
> can use the "/e" modifier to have the "replacement" be
> eval()d by PHP, just like perl.
>
> There is a high potential for exploitable PHP code if a
> programmer uses the /e modifier and does not use quotes
> around the back references (backrefs). Without quotes,
> arbitrary commands may be executed by using the backtick
> operator. Other commands may be executed as well, but are
> more difficult, since addslashes() prevents the characters
> ['"\\\0] from being used.
>
> An clear and explicit warning should be added to the doc
> page for preg_replace, indicating the backrefs must always
> be quoted. Single quotes are preferable, since double
> quotes allow variable expansion.
>
> See the messages below for examples of how this may be
> exploited. (Assume that $a comes from an untrusted source,
> i.e. a get/post/cookie/header variable.)
>
> -James
>
> -- Forwarded message --
> Date: Mon, 3 Feb 2003 01:04:23 -0500 (EST)
> From: James E. Flemer <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] preg_replace oddity [exploitable]
>
> I found a more evil example:
>
>$a = "___! `rm -rf /tmp/sess_*` !___";
> $b = preg_replace("/!(.*)!/e", "print(\\1);", $a);
> ?>
>
> This happily executes "rm -rf /tmp/sess_*". I will not
> give out more examples, but if one examines the code for
> addslashes() it is quite obvious what you can an cannot do
> here. Thus it is clearly a Bad Thing for someone to use
> preg_replace with the /e modifier and not use quotes around
> the \\n or $n backrefs.
>
> The docs should be updated to include a very noticeable
> warning about this hole. I am contemplating possible
> solutions for this problem...
>
> Also as a side note, it does not seem to be possible to use
> 'echo' as part of the expression, print must be used. (Yes
> I know why, just pointing it out.)
>
> -James
>
>
> On Thu, 30 Jan 2003, James E. Flemer wrote:
>
> > Can someone explain what is going on here:
> >
> > --- foo.php ---
> > > $a = "___! 52); echo(42 !___";
> > $b = preg_replace("/!(.*)!/e", "print(\\1);", $a);
> > print("\n---\na: $a\nb: $b\n");
> > ?>
> > --- end ---
> > --- output ---
> > 52
> > ---
> > a: ___! 52); echo(42 !___
> > b: ___1___
> > --- end ---
> >
> > I understand that one is supposed to use single quotes
> > around the \\1 in the above preg_replace. But what happens
> > when they do not? Clearly the echo(42); is not executed,
> > and it is not printed by print(). Even more interesting is
> > if you put something like echo(\"42 in $a, then you get a
> > bunch of errors including:
> > Fatal error - Failed evaluating code:
> > print( 52); echo(\"42 );
> >
> > It seems like preg_replace() is doing some strange things,
> > and might be something that could be exploitable if a
> > remote user can supply the first argument, and the second
> > argument does not enclose \\n options.
> >
> > -James
>
>
>
> --
> PHP Documentation Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....]
On Mon, 3 Feb 2003, Maxim Maletsky wrote: > I don't really want to parse the .c files for protos, that is already > being done by other scripts(*). What I want to try is to compare the > documentation data to the actual C code where possible to get some hints > what is not ideally matching. What has Ilia done and where is it? You'll have to ask Ilia as it's somewhere on his harddrive. Regards, Philip -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22008 [Opn]: fgetss : 0 vs false, html on multiple lines
ID: 22008
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: all
PHP Version: 4.3.0
New Comment:
I've tried the latest CVS and tried to fetch the page you've specified.
As far as I can tell the function had worked correctly, only non-html
output was displayed.
P.S. Philip the fgetss() function is supposed to handle tags that span
multiple lines, so that should not be a problem.
Previous Comments:
[2003-02-02 22:06:07] [EMAIL PROTECTED]
This is something to do with
http://www.w3.org/TR/REC-html40/strict.dtd";>
seems to be causing problem.
Again PHP4.2.3 or earlier treats this without problem.
[2003-02-02 21:08:46] [EMAIL PROTECTED]
Thank you for your comments.
I found this problem only occurs when parsing specific html.
Please try the following URL to see my problem.
Thank you.
http://adds.aviationweather.gov/projects/adds/metars/index.php?metarIds=ksfo";,
"r");
while (($line=fgetss($fp, 4096))!==FALSE) {
echo $line;
}
fclose($fp);
?>
http://adds.aviationweather.gov/projects/adds/metars/index.php?metarIds=ksfo";,
"r");
while (($line = strip_tags(fgets($fp, 4096)))!==FALSE) {
echo $line;
}
fclose($fp);
?>
[2003-02-02 15:46:14] [EMAIL PROTECTED]
c) Add a regarding the 'blank lines' comment from Ilia.
I don't think strip_tags() needs this but maybe it does
(doubtful).
[2003-02-02 15:41:51] [EMAIL PROTECTED]
That or maybe a problem existed because it only gets/strips one line at
a time which makes dealing with html tags spanning multiple lines
not-so-good. So using this fgetss() example script vs
strip_tags(file_get_contents($url)) will yield different results.
Reclassifying as a doc problem for fgetss():
a) Add the 0 vs false entity
b) Add a warning regarding spanning html tags; offer an alternative
[2003-02-02 14:44:04] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
I think the problem you are seeing may stem from incorrect usage of the
fgetss() function. For that reason I am including a sample of a working
code for this function below
http://bugs.php.net/bug.php?id=22008";, "r");
while (($line = fgetss($fp, 4096)) !== FALSE) {
echo $line;
}
fclose($fp);
?>
Note that the output of fgetss gets compared to false, this is very
important because it is quite likely that fgetss() will return 'blanks'
if the line only contains HTML data.
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/22008
--
Edit this bug report at http://bugs.php.net/?id=22008&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....]
I don't really want to parse the .c files for protos, that is already being done by other scripts(*). What I want to try is to compare the documentation data to the actual C code where possible to get some hints what is not ideally matching. What has Ilia done and where is it? -- Maxim Maletsky [EMAIL PROTECTED] Philip Olson <[EMAIL PROTECTED]> wrote... : > On Mon, 3 Feb 2003, Maxim Maletsky wrote: > > Thanks, I think this can be useful to me. > > > > Actually, in base of this (and others out there) script(s), I am going > > to attempt creating a script that parses both the C code and the docs > > tree to look for any inconsistencies. > > > > Somewhat like a doc-bug hunter. The goal in this case will be to > > analyze the current documentation and get listed the functions that do > > not correspond to the current documentation, such as in our case some > > return values and parameter counts. Would be helpful getting a > > machine-generated summary of incorrectly documented protos and functions > > (like for things that have been changed since they were documented etc). > > > > I already saw things doing similar to that, so I've got the base. > > > > Any thoughts/complains/suggestions? If what comes out will work well for > > me and nobody objects, I will then commit it to the /phpdoc/scripts. > > Ilia has already created something that does this and > he's been going through it doing minor tweaks here and > there for awhile now. You may want to talk to him. > > Regards, > Philip > > > > > > > Friedhelm Betz <[EMAIL PROTECTED]> wrote... : > > > > > > > I have heard some rumors about someone creating a proto check script to > > > > > check whether the protos in phpdoc reflect the current protos of > > > > > functions in the php source. Take in account undocumented new > > > > > parameters, etc. too... I don't think that anybody can get on this to do > > > > > it manually in any reasonable time... > > > > > > > > Would be nice to investigate on this deeper and see whether we can do > > > > something about it. I could go ahead to write a similar script myself. > > > > > > Take a look at /phpdoc/scripts/xml_proto.php > > > never tried, but may be a good starting point. > > > > > > Friedhelm > > > > > > > > > -- > > > PHP Documentation Mailing List (http://www.php.net/) > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > > -- > > PHP Documentation Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] preg_replace() docs need expliot warning
A warning about preg_replace() command needs to be added to
the docs page for this command. The preg_replace() command
can use the "/e" modifier to have the "replacement" be
eval()d by PHP, just like perl.
There is a high potential for exploitable PHP code if a
programmer uses the /e modifier and does not use quotes
around the back references (backrefs). Without quotes,
arbitrary commands may be executed by using the backtick
operator. Other commands may be executed as well, but are
more difficult, since addslashes() prevents the characters
['"\\\0] from being used.
An clear and explicit warning should be added to the doc
page for preg_replace, indicating the backrefs must always
be quoted. Single quotes are preferable, since double
quotes allow variable expansion.
See the messages below for examples of how this may be
exploited. (Assume that $a comes from an untrusted source,
i.e. a get/post/cookie/header variable.)
-James
-- Forwarded message --
Date: Mon, 3 Feb 2003 01:04:23 -0500 (EST)
From: James E. Flemer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] preg_replace oddity [exploitable]
I found a more evil example:
This happily executes "rm -rf /tmp/sess_*". I will not
give out more examples, but if one examines the code for
addslashes() it is quite obvious what you can an cannot do
here. Thus it is clearly a Bad Thing for someone to use
preg_replace with the /e modifier and not use quotes around
the \\n or $n backrefs.
The docs should be updated to include a very noticeable
warning about this hole. I am contemplating possible
solutions for this problem...
Also as a side note, it does not seem to be possible to use
'echo' as part of the expression, print must be used. (Yes
I know why, just pointing it out.)
-James
On Thu, 30 Jan 2003, James E. Flemer wrote:
> Can someone explain what is going on here:
>
> --- foo.php ---
>$a = "___! 52); echo(42 !___";
> $b = preg_replace("/!(.*)!/e", "print(\\1);", $a);
> print("\n---\na: $a\nb: $b\n");
> ?>
> --- end ---
> --- output ---
> 52
> ---
> a: ___! 52); echo(42 !___
> b: ___1___
> --- end ---
>
> I understand that one is supposed to use single quotes
> around the \\1 in the above preg_replace. But what happens
> when they do not? Clearly the echo(42); is not executed,
> and it is not printed by print(). Even more interesting is
> if you put something like echo(\"42 in $a, then you get a
> bunch of errors including:
> Fatal error - Failed evaluating code:
> print( 52); echo(\"42 );
>
> It seems like preg_replace() is doing some strange things,
> and might be something that could be exploitable if a
> remote user can supply the first argument, and the second
> argument does not enclose \\n options.
>
> -James
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....] (fwd)
Sorry, I wrote a wrong address for Ilia so here's a correct one. Philip -- Forwarded message -- Date: Mon, 3 Feb 2003 17:46:08 + (GMT) From: Philip Olson <[EMAIL PROTECTED]> To: Maxim Maletsky <[EMAIL PROTECTED]> Cc: Friedhelm Betz <[EMAIL PROTECTED]>, Gabor Hojtsy <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PHP-DOC] proto-skript [was authors] On Mon, 3 Feb 2003, Maxim Maletsky wrote: > Thanks, I think this can be useful to me. > > Actually, in base of this (and others out there) script(s), I am going > to attempt creating a script that parses both the C code and the docs > tree to look for any inconsistencies. > > Somewhat like a doc-bug hunter. The goal in this case will be to > analyze the current documentation and get listed the functions that do > not correspond to the current documentation, such as in our case some > return values and parameter counts. Would be helpful getting a > machine-generated summary of incorrectly documented protos and functions > (like for things that have been changed since they were documented etc). > > I already saw things doing similar to that, so I've got the base. > > Any thoughts/complains/suggestions? If what comes out will work well for > me and nobody objects, I will then commit it to the /phpdoc/scripts. Ilia has already created something that does this and he's been going through it doing minor tweaks here and there for awhile now. You may want to talk to him. Regards, Philip > Friedhelm Betz <[EMAIL PROTECTED]> wrote... : > > > > > I have heard some rumors about someone creating a proto check script to > > > > check whether the protos in phpdoc reflect the current protos of > > > > functions in the php source. Take in account undocumented new > > > > parameters, etc. too... I don't think that anybody can get on this to do > > > > it manually in any reasonable time... > > > > > > Would be nice to investigate on this deeper and see whether we can do > > > something about it. I could go ahead to write a similar script myself. > > > > Take a look at /phpdoc/scripts/xml_proto.php > > never tried, but may be a good starting point. > > > > Friedhelm > > > > > > -- > > PHP Documentation Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....]
On Mon, 3 Feb 2003, Maxim Maletsky wrote: > Thanks, I think this can be useful to me. > > Actually, in base of this (and others out there) script(s), I am going > to attempt creating a script that parses both the C code and the docs > tree to look for any inconsistencies. > > Somewhat like a doc-bug hunter. The goal in this case will be to > analyze the current documentation and get listed the functions that do > not correspond to the current documentation, such as in our case some > return values and parameter counts. Would be helpful getting a > machine-generated summary of incorrectly documented protos and functions > (like for things that have been changed since they were documented etc). > > I already saw things doing similar to that, so I've got the base. > > Any thoughts/complains/suggestions? If what comes out will work well for > me and nobody objects, I will then commit it to the /phpdoc/scripts. Ilia has already created something that does this and he's been going through it doing minor tweaks here and there for awhile now. You may want to talk to him. Regards, Philip > Friedhelm Betz <[EMAIL PROTECTED]> wrote... : > > > > > I have heard some rumors about someone creating a proto check script to > > > > check whether the protos in phpdoc reflect the current protos of > > > > functions in the php source. Take in account undocumented new > > > > parameters, etc. too... I don't think that anybody can get on this to do > > > > it manually in any reasonable time... > > > > > > Would be nice to investigate on this deeper and see whether we can do > > > something about it. I could go ahead to write a similar script myself. > > > > Take a look at /phpdoc/scripts/xml_proto.php > > never tried, but may be a good starting point. > > > > Friedhelm > > > > > > -- > > PHP Documentation Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....]
Friedhelm Betz wrote: Take a look at /phpdoc/scripts/xml_proto.php never tried, but may be a good starting point. the ext_skel script has functionality to parse protos and generate from it somewhere hidden in it, too ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 Sie finden uns auf der CeBIT in Halle 6/H44 http://www.six.de/cebit2003/ -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #21998 [Ver->Ana]: array_pop() moves current element pointer since 4.3.0
ID: 21998 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Analyzed -Bug Type: Arrays related +Bug Type: Documentation problem Operating System: all PHP Version: 4.3.0 New Comment: I have fixed this now in CVS. But the docs should mention that the pointer is reset by array_pop/array_shift. Previous Comments: [2003-02-03 10:51:39] [EMAIL PROTECTED] Clarification: In PHP 4.2.3, the current array position was reset after array_pop() and array_shift(). [2003-02-03 00:39:14] [EMAIL PROTECTED] [EMAIL PROTECTED]: I reverted my changes, not my fault. :-p But there is indeed some bug in this, since array_pop() should not affect the current key. [2003-02-01 15:08:57] [EMAIL PROTECTED] Array related. One of these commits broke it. revision 1.180 date: 2002/08/01 17:34:31; author: rodif_bl; state: Exp; lines: +12 -15 array_pop wasnt setting next index revision 1.179 date: 2002/08/01 16:44:47; author: sniper; state: Exp; lines: +1 -4 That was not correct.. revision 1.178 date: 2002/08/01 16:39:52; author: sniper; state: Exp; lines: +5 -2 Reset index when doing array_pop() [2003-02-01 13:42:12] [EMAIL PROTECTED] This prints "bool(false)" in 4.3.0 (current element pointer points somewhere out of the array) and var_dump($a[0]) in 4.2.3 (array is reset after array_pop). I had to add many additional reset()'s after installing 4.3.0. How array_pop() (and may be others) affects current element pointer is not documented, so this behavior is not a bug. The only purpose of writing all this is that I want to know how array_pop() will work in future PHP releases. -- Edit this bug report at http://bugs.php.net/?id=21998&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22032 [Opn->Bgs]: date() Function - Incorrect Word
ID: 22032 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Already fixed, wait the update of the manual. Previous Comments: [2003-02-03 10:26:33] [EMAIL PROTECTED] Picky error: On function.date.php (documentation for date() function) under the D format character, it reads 'week' where it should read 'day' or 'weekday' or something else. Hans -- Edit this bug report at http://bugs.php.net/?id=22032&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22032 [NEW]: date() Function - Incorrect Word
From: [EMAIL PROTECTED] Operating system: PHP version: 4.3.0 PHP Bug Type: Documentation problem Bug description: date() Function - Incorrect Word Picky error: On function.date.php (documentation for date() function) under the D format character, it reads 'week' where it should read 'day' or 'weekday' or something else. Hans -- Edit bug report at http://bugs.php.net/?id=22032&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22032&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22032&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22032&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22032&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22032&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22032&r=support Expected behavior: http://bugs.php.net/fix.php?id=22032&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22032&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22032&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22032&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22032&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22032&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22032&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22032&r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] proto-skript [was authors....]
Thanks, I think this can be useful to me. Actually, in base of this (and others out there) script(s), I am going to attempt creating a script that parses both the C code and the docs tree to look for any inconsistencies. Somewhat like a doc-bug hunter. The goal in this case will be to analyze the current documentation and get listed the functions that do not correspond to the current documentation, such as in our case some return values and parameter counts. Would be helpful getting a machine-generated summary of incorrectly documented protos and functions (like for things that have been changed since they were documented etc). I already saw things doing similar to that, so I've got the base. Any thoughts/complains/suggestions? If what comes out will work well for me and nobody objects, I will then commit it to the /phpdoc/scripts. -- Maxim Maletsky [EMAIL PROTECTED] Friedhelm Betz <[EMAIL PROTECTED]> wrote... : > > > I have heard some rumors about someone creating a proto check script to > > > check whether the protos in phpdoc reflect the current protos of > > > functions in the php source. Take in account undocumented new > > > parameters, etc. too... I don't think that anybody can get on this to do > > > it manually in any reasonable time... > > > > Would be nice to investigate on this deeper and see whether we can do > > something about it. I could go ahead to write a similar script myself. > > Take a look at /phpdoc/scripts/xml_proto.php > never tried, but may be a good starting point. > > Friedhelm > > > -- > PHP Documentation Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22005 [Bgs->Opn]: mysql_stat space problems
ID: 22005
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
-Bug Type: MySQL related
+Bug Type: Documentation problem
Operating System: ALL
PHP Version: 4.3.0
New Comment:
Reclassified as a documentation bug
Previous Comments:
[2003-02-03 06:05:44] [EMAIL PROTECTED]
Ok, this is verified but this is not a PHP's bug, but a MySQL's. Please
post a MySQL's bug.
[2003-02-02 11:32:47] [EMAIL PROTECTED]
a) split/preg_split uses regex, not explode
b) it would not work well as it'd split up everything
c) this is not related to html but rather a php string
d) the example in the manual uses explode on two spaces
If this is indeed true (one space before Queries) than this is a bug
... somewhere.
[2003-02-02 03:23:43] [EMAIL PROTECTED]
In fact there are more space but the HTML output will read only one.
Use explode('[[:space:]]',$var) to divide it.
(You can verify that by looking at the HTML source.
[2003-02-01 21:26:48] [EMAIL PROTECTED]
When I call mysql_stat(), it returns a string like this:
Uptime: 1182208 Threads: 13 Questions: 745284 Slow queries: 1
Opens: 2210 Flush tables: 1 Open tables: 12 Queries per second avg:
0.630
All the fields are supposed to have two spaces (" ") between each of
them so that an explode() will work on it.
However, you will notice that there is only 1 space (" ") between the
value of "Open Tables" and the caption "Queries per second avg:"
Is this how it is supposed to be? Or is this a minor bug?
--
Edit this bug report at http://bugs.php.net/?id=22005&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22011 [Csd->Opn]: php -n does not work as expected
ID: 22011
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Documentation problem
Operating System: linux RH 8.0
PHP Version: 4.3.0
New Comment:
reopening as closed by accident
Previous Comments:
[2003-02-03 05:59:22] [EMAIL PROTECTED]
To clarify my first submission:
-n switch passed to the CLI scans this additional ini file(s) and uses
the values found inside.
easy to reproduce:
let config-file-path be /etc
let config-file-scan-dir be /opt/php
origin /etc/php.ini sets register_globals off
/opt/php/php.ini sets register_globals on
php -n -r 'echo ini_get('register_globals') . "\n";'
php -r 'echo ini_get('register_globals') . "\n";'
yields the same results, shown that additional ini files are scanned,
parsed and applied.
Therefore it seems that -n has the only effect, that the php.ini in
config-file-path is ignored, but additional ini-files are parsed and
their values applied.
Again: is this expected behaviour?
Regards
Friedhelm Betz
[2003-02-03 05:12:54] [EMAIL PROTECTED]
-n switch should also ignore ini files defined
--with-config-file-scan-dir. Re-opening.
[2003-02-02 19:07:49] [EMAIL PROTECTED]
This switch is not documented so far and if this is not a bug but
expected behaviour let it be at least a doc problem;-)
Regards
Friedhelm Betz
[2003-02-02 18:51:40] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Please ask such questions on [EMAIL PROTECTED]
[2003-02-02 08:13:58] [EMAIL PROTECTED]
Hi,
if php CLI was configured:
--with-config-file-path=/etc
--with-config-file-scan-dir=/some/directory
-n switch passed to the CLI scans this additional ini file(s).
php -h says
-n No php.ini file will be used
Does this "No" exclude additional ini-files?
PHP 4.3.0 (cli)
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.zlib
Regards
Friedhelm Betz
--
Edit this bug report at http://bugs.php.net/?id=22011&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22011 [Opn->Csd]: php -n does not work as expected
ID: 22011
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: linux RH 8.0
PHP Version: 4.3.0
New Comment:
To clarify my first submission:
-n switch passed to the CLI scans this additional ini file(s) and uses
the values found inside.
easy to reproduce:
let config-file-path be /etc
let config-file-scan-dir be /opt/php
origin /etc/php.ini sets register_globals off
/opt/php/php.ini sets register_globals on
php -n -r 'echo ini_get('register_globals') . "\n";'
php -r 'echo ini_get('register_globals') . "\n";'
yields the same results, shown that additional ini files are scanned,
parsed and applied.
Therefore it seems that -n has the only effect, that the php.ini in
config-file-path is ignored, but additional ini-files are parsed and
their values applied.
Again: is this expected behaviour?
Regards
Friedhelm Betz
Previous Comments:
[2003-02-03 05:12:54] [EMAIL PROTECTED]
-n switch should also ignore ini files defined
--with-config-file-scan-dir. Re-opening.
[2003-02-02 19:07:49] [EMAIL PROTECTED]
This switch is not documented so far and if this is not a bug but
expected behaviour let it be at least a doc problem;-)
Regards
Friedhelm Betz
[2003-02-02 18:51:40] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Please ask such questions on [EMAIL PROTECTED]
[2003-02-02 08:13:58] [EMAIL PROTECTED]
Hi,
if php CLI was configured:
--with-config-file-path=/etc
--with-config-file-scan-dir=/some/directory
-n switch passed to the CLI scans this additional ini file(s).
php -h says
-n No php.ini file will be used
Does this "No" exclude additional ini-files?
PHP 4.3.0 (cli)
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.zlib
Regards
Friedhelm Betz
--
Edit this bug report at http://bugs.php.net/?id=22011&edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #22011 [Csd->Opn]: php -n does not work as expected
ID: 22011 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Documentation problem Operating System: linux RH 8.0 PHP Version: 4.3.0 New Comment: -n switch should also ignore ini files defined --with-config-file-scan-dir. Re-opening. Previous Comments: [2003-02-02 19:07:49] [EMAIL PROTECTED] This switch is not documented so far and if this is not a bug but expected behaviour let it be at least a doc problem;-) Regards Friedhelm Betz [2003-02-02 18:51:40] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Please ask such questions on [EMAIL PROTECTED] [2003-02-02 08:13:58] [EMAIL PROTECTED] Hi, if php CLI was configured: --with-config-file-path=/etc --with-config-file-scan-dir=/some/directory -n switch passed to the CLI scans this additional ini file(s). php -h says -n No php.ini file will be used Does this "No" exclude additional ini-files? PHP 4.3.0 (cli) PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 20021010 Debug Build => no Thread Safety => disabled Registered PHP Streams => php, http, ftp, https, ftps, compress.zlib Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=22011&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Re: PHP documentation authors / editors and license
On Sunday, February 2, 2003, at 03:13 AM, Zak Greant wrote: Heh. The content is already in docbook and the user notes are mostly useless already. ;) *wakes from a long slumber* Depends on coding style (the notes), doesn't it? I used to bitch about PHP2->3 migrations, now I have 3->4, and 4->5(?). Revenue for me, but... Seriously, of course it is better that we use what we have and just change to a better license. However, we do have options - this being one of them. :) For the PHP ER, I spent a *little* bit of time revising old docs. It was a bit sad, seeing how many simple protos were... to put it gently, not currently accurate. It (the PHP ER work) knocked me out of docs for a while. Somewhere around here I have information to get paid for it... I never sent it in. Heh. For proper tribute, multiple CVS dumps should allow for *all* of the applicable authors to be listed. It sounds a bit like the BSD license, but what is the cost of 2 (or even 12) pages of 6 point text in a thousand page manual? About nothing. Web costs? Even less. Give the chapter-slaves their credit, the editor folks their credit, the one brilliant example their creditetc. Or, switch from an old über-editor-batch to a "new" über-editor-batch... hmm. -Ronabop -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
