[PHP-DOC] #36442 [NEW]: preg_match's examples shouldn't always use / as delimiter
From: [EMAIL PROTECTED] Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: preg_match's examples shouldn't always use / as delimiter Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit bug report at http://bugs.php.net/?id=36442edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36442r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36442r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36442r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36442r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36442r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36442r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36442r=needscript Try newer version:http://bugs.php.net/fix.php?id=36442r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36442r=support Expected behavior:http://bugs.php.net/fix.php?id=36442r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36442r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36442r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36442r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36442r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36442r=dst IIS Stability:http://bugs.php.net/fix.php?id=36442r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36442r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36442r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36442r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36442r=mysqlcfg
[PHP-DOC] #36442 [Opn]: preg_match's examples shouldn't always use / as delimiter
ID: 36442 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. Previous Comments: [2006-02-18 16:05:49] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 14:48:34] [EMAIL PROTECTED] Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit this bug report at http://bugs.php.net/?id=36442edit=1
[PHP-DOC] #36442 [Opn]: preg_match's examples shouldn't always use / as delimiter
ID: 36442 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. Previous Comments: [2006-02-18 14:48:34] [EMAIL PROTECTED] Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit this bug report at http://bugs.php.net/?id=36442edit=1
[PHP-DOC] #36442 [Opn]: preg_match's examples shouldn't always use / as delimiter
ID: 36442 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: In the examples of other pcre functions, | was often used as an alternative. (e.g. http://php.net/preg_match_all http://php.net/preg_replace_callback) The fact that chars used as delimiter must be escaped in the regex is already stated here: http://php.net/pcre#pcre.intro The point is : having to escape a delimiter in the regex is almost always due to a wrong choice of delimiter. So must we demonstrate that wrong choice ? I agree that the alternative could be another char, like !. But then the examples using | could be changed. Is it worth it ? Anyway, the . escaped in a character class must be changed, because it would fail using the PCRE_EXTRA (X) modifier (I agree that its not ofted used but still ;) ). Previous Comments: [2006-02-18 16:05:51] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 16:05:49] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 14:48:34] [EMAIL PROTECTED] Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit this bug report at http://bugs.php.net/?id=36442edit=1
[PHP-DOC] #36442 [Opn]: preg_match's examples shouldn't always use / as delimiter
ID: 36442 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: Rectification: it will work using X PCRE_EXTRA modifier, my bad. Previous Comments: [2006-02-18 16:41:35] [EMAIL PROTECTED] In the examples of other pcre functions, | was often used as an alternative. (e.g. http://php.net/preg_match_all http://php.net/preg_replace_callback) The fact that chars used as delimiter must be escaped in the regex is already stated here: http://php.net/pcre#pcre.intro The point is : having to escape a delimiter in the regex is almost always due to a wrong choice of delimiter. So must we demonstrate that wrong choice ? I agree that the alternative could be another char, like !. But then the examples using | could be changed. Is it worth it ? Anyway, the . escaped in a character class must be changed, because it would fail using the PCRE_EXTRA (X) modifier (I agree that its not ofted used but still ;) ). [2006-02-18 16:05:51] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 16:05:49] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 14:48:34] [EMAIL PROTECTED] Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit this bug report at http://bugs.php.net/?id=36442edit=1
[PHP-DOC] #36447 [NEW]: imagefill page, example one has invalid parameter count
From: todd at magnifisites dot com
Operating system: Any
PHP version: Irrelevant
PHP Bug Type: Documentation problem
Bug description: imagefill page, example one has invalid parameter count
Description:
Example 1 has an invalid parameter count in the documentation. The line
reading ...
$im = imagecreatetruecolor('example.jpg', 100, 100);
... is in error.
Expected result:
A working example:
?php
$im = imagecreatetruecolor(100, 100);
// sets background to red
$red = imagecolorallocate($im, 255, 0, 0);
imagefill($im, 0, 0, $red);
header(Content-type: image/png);
imagepng($im);
imagedestroy($im);
?
--
Edit bug report at http://bugs.php.net/?id=36447edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36447r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36447r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36447r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36447r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36447r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36447r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36447r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36447r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36447r=support
Expected behavior:http://bugs.php.net/fix.php?id=36447r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36447r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36447r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36447r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36447r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36447r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36447r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36447r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36447r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36447r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36447r=mysqlcfg
[PHP-DOC] #36448 [NEW]: Meaningless acronym tag in docs
From: gareth dot adams at gmail dot com Operating system: N/A PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Meaningless acronym tag in docs Description: The introduction to PHP page on the website contains an acronym tag with no title attribute, thereby making it useless as an acronym tag. From http://php.net/manual/en/introduction.php h1 class=sect1a name=intro-whatisWhat is PHP?/a/h1p acronym class=acronymPHP/acronym (recursive ... I'm pretty sure the master manual is not stored in HTML format, so either this is a simple mistake in the documentation or a problem with the HTML converter I think the problem was pointed out at http://bugs.php.net/bug.php?id=10498 but marked bogus due to a bad description -- Edit bug report at http://bugs.php.net/?id=36448edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36448r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36448r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36448r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36448r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36448r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36448r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36448r=needscript Try newer version:http://bugs.php.net/fix.php?id=36448r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36448r=support Expected behavior:http://bugs.php.net/fix.php?id=36448r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36448r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36448r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36448r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36448r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36448r=dst IIS Stability:http://bugs.php.net/fix.php?id=36448r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36448r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36448r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36448r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36448r=mysqlcfg
[PHP-DOC] cvs: phpdoc /en/reference/image/functions imagefill.xml
nlopess Sat Feb 18 20:14:48 2006 UTC
Modified files:
/phpdoc/en/reference/image/functionsimagefill.xml
Log:
fix #36447: example doesnt work
http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/image/functions/imagefill.xml?r1=1.6r2=1.7diff_format=u
Index: phpdoc/en/reference/image/functions/imagefill.xml
diff -u phpdoc/en/reference/image/functions/imagefill.xml:1.6
phpdoc/en/reference/image/functions/imagefill.xml:1.7
--- phpdoc/en/reference/image/functions/imagefill.xml:1.6 Mon Jan 2
09:37:26 2006
+++ phpdoc/en/reference/image/functions/imagefill.xml Sat Feb 18 20:14:48 2006
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.6 $ --
+!-- $Revision: 1.7 $ --
!-- splitted from ./en/functions/image.xml, last change in rev 1.2 --
refentry id=function.imagefill
refnamediv
@@ -28,12 +28,15 @@
![CDATA[
?php
-$im = imagecreatetruecolor('example.jpg', 100, 100);
+$im = imagecreatetruecolor(100, 100);
// sets background to red
$red = imagecolorallocate($im, 255, 0, 0);
imagefill($im, 0, 0, $red);
+header('Content-type: image/png');
+imagepng($im);
+imagedestroy($im);
?
]]
/programlisting
[PHP-DOC] #36447 [Opn-Csd]: imagefill page, example one has invalid parameter count
ID: 36447
Updated by: [EMAIL PROTECTED]
Reported By: todd at magnifisites dot com
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Any
PHP Version: Irrelevant
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2006-02-18 20:57:19] todd at magnifisites dot com
Description:
Example 1 has an invalid parameter count in the documentation. The
line reading ...
$im = imagecreatetruecolor('example.jpg', 100, 100);
... is in error.
Expected result:
A working example:
?php
$im = imagecreatetruecolor(100, 100);
// sets background to red
$red = imagecolorallocate($im, 255, 0, 0);
imagefill($im, 0, 0, $red);
header(Content-type: image/png);
imagepng($im);
imagedestroy($im);
?
--
Edit this bug report at http://bugs.php.net/?id=36447edit=1
[PHP-DOC] cvs: phpdoc /en/language/oop5 reflection.xml
nlopess Sat Feb 18 20:23:31 2006 UTC Modified files: /phpdoc/en/language/oop5reflection.xml Log: catch up with latest PHP 5.1 http://cvs.php.net/viewcvs.cgi/phpdoc/en/language/oop5/reflection.xml?r1=1.17r2=1.18diff_format=u Index: phpdoc/en/language/oop5/reflection.xml diff -u phpdoc/en/language/oop5/reflection.xml:1.17 phpdoc/en/language/oop5/reflection.xml:1.18 --- phpdoc/en/language/oop5/reflection.xml:1.17 Wed Jan 11 10:24:59 2006 +++ phpdoc/en/language/oop5/reflection.xml Sat Feb 18 20:23:31 2006 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.17 $ -- +!-- $Revision: 1.18 $ -- sect1 id=language.oop5.reflection titleReflection/title sect2 id=language.oop5.reflection.introduction @@ -246,7 +246,7 @@ public static string export(mixed function, mixed parameter, bool return) public string getName() public bool isPassedByReference() -public ReflectionClass getClass() +public ReflectionClass getDeclaringClass() public bool isArray() public bool allowsNull() public bool isOptional() @@ -350,6 +350,7 @@ public int getModifiers() public bool isInstance(stdclass object) public stdclass newInstance(mixed args) +public stdclass newInstanceArgs(array args) public ReflectionClass getParentClass() public bool isSubclassOf(ReflectionClass class) public array getStaticProperties() @@ -369,7 +370,8 @@ simpara functionhasConstant/function, functionhasMethod/function, functionhasProperty/function, functiongetStaticPropertyValue/function - and functionsetStaticPropertyValue/function were added in PHP 5.1.0. + and functionsetStaticPropertyValue/function were added in PHP 5.1.0, while + functionnewInstanceArgs/function was added in PHP 5.1.3. /simpara /note para
[PHP-DOC] #36448 [Opn-Fbk]: Meaningless acronym tag in docs
ID: 36448 Updated by: [EMAIL PROTECTED] Reported By: gareth dot adams at gmail dot com -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: Quoting from the HTML spec: --- The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. [...] Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers. [...] The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. --- It is clear from this text, that the title attribute is not required, and it is quite useful to mark up such content with the acronym tag regardless. Previous Comments: [2006-02-18 21:13:22] gareth dot adams at gmail dot com Description: The introduction to PHP page on the website contains an acronym tag with no title attribute, thereby making it useless as an acronym tag. From http://php.net/manual/en/introduction.php h1 class=sect1a name=intro-whatisWhat is PHP?/a/h1p acronym class=acronymPHP/acronym (recursive ... I'm pretty sure the master manual is not stored in HTML format, so either this is a simple mistake in the documentation or a problem with the HTML converter I think the problem was pointed out at http://bugs.php.net/bug.php?id=10498 but marked bogus due to a bad description -- Edit this bug report at http://bugs.php.net/?id=36448edit=1
[PHP-DOC] cvs: phpdoc /en/reference/pdf reference.xml
katja Sat Feb 18 21:43:04 2006 UTC Modified files: /phpdoc/en/reference/pdfreference.xml Log: update or add pdf functions http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/pdf/reference.xml?r1=1.20r2=1.21diff_format=u Index: phpdoc/en/reference/pdf/reference.xml diff -u phpdoc/en/reference/pdf/reference.xml:1.20 phpdoc/en/reference/pdf/reference.xml:1.21 --- phpdoc/en/reference/pdf/reference.xml:1.20 Mon Dec 12 23:01:59 2005 +++ phpdoc/en/reference/pdf/reference.xml Sat Feb 18 21:43:04 2006 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.20 $ -- +!-- $Revision: 1.21 $ -- !-- Purpose: utilspec.nontext -- !-- Membership: pecl, external -- @@ -34,18 +34,39 @@ thorough explanation of the coordinate system used. /para para -With version 6, PDFlib offers an object oriented API for PHP 5 in -addition to the function oriented API for PHP 4. The main difference is -the following: In PHP 4, first a PDF resource has to be retrieved -with a function call like function$p = PDF_new();/function -which is used as the first parameter in all further function calls, e.g. -as in functionPDF_begin_document($p, , )/function. -In PHP 5, a PDFlib object is created with -function$p = new PDFlib()/function instead. This object offers -all PDFlib API functions as methods, e.g. as with -function$p-begin_document(, )/function. -In addition, exceptions have been introduced in PHP 5 which are -supported by PDFlib 6 and later as well. + With version 6, PDFlib offers an object oriented API for PHP 5 in + addition to the function oriented API for PHP 4. The main difference is + the following: + /para +para + In PHP 4, first a PDF resource has to be retrieved + with a function call like +/para +para + $p = PDF_new(). +/para +para + This PDF resource is used as the first parameter in all further function calls, such + as in +/para +para + PDF_begin_document($p, , ). +/para +para + In PHP 5 however, a PDFlib object is created with +/para +para +$p = new PDFlib(). +/para +para + This object offers all PDFlib API functions as methods, e.g. as with + /para +para + $p-begin_document(, ). +/para +para + In addition, exceptions have been introduced in PHP 5 which are + supported by PDFlib 6 and later as well. /para para Please see the link linkend=pdf.examplesexamples/link below for
[PHP-DOC] cvs: phpdoc /en/reference/pcre/functions preg-match.xml
nlopess Sat Feb 18 22:44:06 2006 UTC
Modified files:
/phpdoc/en/reference/pcre/functions preg-match.xml
Log:
improve last example's regex
http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/pcre/functions/preg-match.xml?r1=1.19r2=1.20diff_format=u
Index: phpdoc/en/reference/pcre/functions/preg-match.xml
diff -u phpdoc/en/reference/pcre/functions/preg-match.xml:1.19
phpdoc/en/reference/pcre/functions/preg-match.xml:1.20
--- phpdoc/en/reference/pcre/functions/preg-match.xml:1.19 Fri Jun 24
09:11:45 2005
+++ phpdoc/en/reference/pcre/functions/preg-match.xml Sat Feb 18 22:44:06 2006
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.19 $ --
+!-- $Revision: 1.20 $ --
!-- splitted from ./en/functions/pcre.xml, last change in rev 1.2 --
refentry id=function.preg-match
refnamediv
@@ -180,19 +180,17 @@
![CDATA[
?php
// get host name from URL
-preg_match(/^(http:\/\/)?([^\/]+)/i,
+preg_match('@^(?:http://)?([^/]+)@i',
http://www.php.net/index.html;, $matches);
-$host = $matches[2];
+$host = $matches[1];
// get last two segments of host name
-preg_match(/[^\.\/]+\.[^\.\/]+$/, $host, $matches);
+preg_match('/[^.]+\.[^.]+$/', $host, $matches);
echo domain name is: {$matches[0]}\n;
?
]]
/programlisting
- para
- This example will produce:
- /para
+ example.outputs;
screen
![CDATA[
domain name is: php.net
[PHP-DOC] #36442 [Opn-Csd]: preg_match's examples shouldn't always use / as delimiter
ID: 36442 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: ok, regex improved. Previous Comments: [2006-02-18 16:45:48] [EMAIL PROTECTED] Rectification: it will work using X PCRE_EXTRA modifier, my bad. [2006-02-18 16:41:35] [EMAIL PROTECTED] In the examples of other pcre functions, | was often used as an alternative. (e.g. http://php.net/preg_match_all http://php.net/preg_replace_callback) The fact that chars used as delimiter must be escaped in the regex is already stated here: http://php.net/pcre#pcre.intro The point is : having to escape a delimiter in the regex is almost always due to a wrong choice of delimiter. So must we demonstrate that wrong choice ? I agree that the alternative could be another char, like !. But then the examples using | could be changed. Is it worth it ? Anyway, the . escaped in a character class must be changed, because it would fail using the PCRE_EXTRA (X) modifier (I agree that its not ofted used but still ;) ). [2006-02-18 16:05:51] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 16:05:49] [EMAIL PROTECTED] I'm not sure of the merit of using a different delimiter there since it demonstrates that if the delimiter does exist, it should be escaped. However if it is changed, I think '|' is a bad choice because it's part of PCRE syntax. [2006-02-18 14:48:34] [EMAIL PROTECTED] Description: In the manual page of preg_match, / is always used as delimiter, even if there are /s in the regex. It could influences bad habbits on readers. There are also too many escaped chars. Here is the patch containing the proposed changes: http://www.colder.ch/patches/preg-match.patch -- Edit this bug report at http://bugs.php.net/?id=36442edit=1
[PHP-DOC] cvs: phpdoc /en/reference/datetime/functions mktime.xml
nlopess Sat Feb 18 22:55:35 2006 UTC Modified files: /phpdoc/en/reference/datetime/functions mktime.xml Log: fix #36401: year, month and day can be passed as 0 http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/datetime/functions/mktime.xml?r1=1.20r2=1.21diff_format=u Index: phpdoc/en/reference/datetime/functions/mktime.xml diff -u phpdoc/en/reference/datetime/functions/mktime.xml:1.20 phpdoc/en/reference/datetime/functions/mktime.xml:1.21 --- phpdoc/en/reference/datetime/functions/mktime.xml:1.20 Mon Aug 15 16:01:08 2005 +++ phpdoc/en/reference/datetime/functions/mktime.xml Sat Feb 18 22:55:35 2006 @@ -1,5 +1,5 @@ ?xml version=1.0 encoding=iso-8859-1? -!-- $Revision: 1.20 $ -- +!-- $Revision: 1.21 $ -- !-- splitted from ./en/functions/datetime.xml, last change in rev 1.2 -- refentry id=function.mktime refnamediv @@ -122,8 +122,8 @@ para functionmktime/function returns the Unix timestamp of the arguments given. - If the arguments are invalid (eg. if the year, month and day are all 0), the - function returns false; (before PHP 5.1 it returned literal-1/literal). + If the arguments are invalid, the function returns false; (before PHP 5.1 + it returned literal-1/literal). /para /refsect1 @@ -149,6 +149,8 @@ The parameteris_dst/parameter parameter became deprecated. Made the function return false; on error, instead of literal-1/literal. +Fixed the function to accept the year, month and day to be all passed +as zero. /entry /row /tbody
[PHP-DOC] #36401 [Opn-Csd]: Bug in mktime()
ID: 36401
Updated by: [EMAIL PROTECTED]
Reported By: marcel dot alburg at alkronet dot info
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 5.1.2
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2006-02-15 15:32:49] [EMAIL PROTECTED]
6 0's here is not invalid, so marking as a doc problem.
[2006-02-15 15:16:09] [EMAIL PROTECTED]
Ah, but, the documentation says:
If the arguments are invalid (eg. if the year, month and day are all
0), the function returns FALSE (before PHP 5.1 it returned -1).
Furthermore, I've just tested on an ancient PHP 4.0 I had lying around,
and mktime(0,0,0,0,0,0) does indeed return -1.
So it seems there's something to be resolved here, whether it be fixing
mktime or changing the documentation.
[2006-02-15 13:42:42] marcel dot alburg at alkronet dot info
but in previosly versions it get 0 back.
because that i mean it's an error
thanks
marcel alburg
[2006-02-15 13:35:19] [EMAIL PROTECTED]
Why? The result is correct. You're getting the timestamp for 0
january-1 (december of the previous year), year 0 (which is 2000) at
00:00:00. This is exactly 30 november 1999, 00:00:00
[2006-02-15 13:31:15] marcel dot alburg at alkronet dot info
Description:
If i enter
print mktime(0,0,0,0,0,0)
i get 943916400 but it must be 0
print date('r', mktime(0,0,0,0,0,0));
returns
Tue, 30 Nov 1999 00:00:00 +0100
Marcel Alburg
Reproduce code:
---
print mktime(0,0,0,0,0,0);
returns 943916400
Expected result:
mktime(0,0,0,0,0,0) must be 0
--
Edit this bug report at http://bugs.php.net/?id=36401edit=1
[PHP-DOC] cvs: phpdoc /en/language operators.xml
nlopess Sat Feb 18 23:10:39 2006 UTC
Modified files:
/phpdoc/en/language operators.xml
Log:
fix #36280: only plain ascii characters can be incremented
http://cvs.php.net/viewcvs.cgi/phpdoc/en/language/operators.xml?r1=1.100r2=1.101diff_format=u
Index: phpdoc/en/language/operators.xml
diff -u phpdoc/en/language/operators.xml:1.100
phpdoc/en/language/operators.xml:1.101
--- phpdoc/en/language/operators.xml:1.100 Fri Feb 17 14:03:06 2006
+++ phpdoc/en/language/operators.xmlSat Feb 18 23:10:39 2006
@@ -1,5 +1,5 @@
?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.100 $ --
+!-- $Revision: 1.101 $ --
chapter id=language.operators
titleOperators/title
simpara
@@ -867,7 +867,8 @@
PHP follows Perl's convention when dealing with arithmetic operations
on character variables and not C's. For example, in Perl 'Z'+1 turns
into 'AA', while in C 'Z'+1 turns into '[' ( ord('Z') == 90, ord('[') ==
91 ).
-Note that character variables can be incremented but not decremented.
+Note that character variables can be incremented but not decremented and
+even so only plain ASCII characters (a-z and A-Z) are supported.
example
titleArithmetic Operations on Character Variables/title
programlisting role=php
[PHP-DOC] #36280 [Opn-Csd]: Character increment - problems with non-english chars
ID: 36280 Updated by: [EMAIL PROTECTED] Reported By: dekelb at gmail dot com -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.4.2 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2006-02-04 12:46:11] [EMAIL PROTECTED] Yes, characters that are not in a-zA-Z not supported. Reclassified as docu problem. [2006-02-04 05:31:20] dekelb at gmail dot com Description: I've search for similar bug, but nothing found. If I missed it please ignore this post :) The manual mentioned the character increment, but there is no reference for English characters only. When I'm trying character increment on Hebrew chars (and I guess with any non-english chars it will be the same) the output of the script is just the same as the original char: ? $a = à echo ++$a; ? The expected result is the following char (which is á), but the result is the same char. Notice that ++ on à9 results with 9 changes to 0, but the Hebrew char isn't incremented. (The encoding I used for this post is windows-1255/iso-8859-8-i). -- Edit this bug report at http://bugs.php.net/?id=36280edit=1
[PHP-DOC] #36448 [Fbk]: Meaningless acronym tag in docs
ID: 36448 Updated by: [EMAIL PROTECTED] Reported By: gareth dot adams at gmail dot com Status: Feedback Bug Type: Documentation problem Operating System: N/A PHP Version: Irrelevant New Comment: On the phpdoc TODO list is a Implement the Acronym tag TODO. It's been there for awhile and most likely will wait until livedocs is online but anyway... :) Here's a thread on the topic: http://marc.theaimsgroup.com/?l=phpdocm=103679111400458 Previous Comments: [2006-02-18 22:18:36] [EMAIL PROTECTED] Quoting from the HTML spec: --- The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. [...] Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers. [...] The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression. --- It is clear from this text, that the title attribute is not required, and it is quite useful to mark up such content with the acronym tag regardless. [2006-02-18 21:13:22] gareth dot adams at gmail dot com Description: The introduction to PHP page on the website contains an acronym tag with no title attribute, thereby making it useless as an acronym tag. From http://php.net/manual/en/introduction.php h1 class=sect1a name=intro-whatisWhat is PHP?/a/h1p acronym class=acronymPHP/acronym (recursive ... I'm pretty sure the master manual is not stored in HTML format, so either this is a simple mistake in the documentation or a problem with the HTML converter I think the problem was pointed out at http://bugs.php.net/bug.php?id=10498 but marked bogus due to a bad description -- Edit this bug report at http://bugs.php.net/?id=36448edit=1
