[PHP-DOC] #40522 [Csd-Opn]: PATCH: reword encoding param note in mb-strrpos
ID: 40522 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Closed +Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: There is no such term as back compatibility in computer parlance. The term is backward compatibility or backwards compatibility: Google Hits phpdoc grep back: 71,100 1* backward: 1,130,000 7 backwards: 1,160,000 8 * Your entry. Previous Comments: [2007-02-25 10:50:23] [EMAIL PROTECTED] I don't feel the change back to backward is necessary. If you wish to submit a patch that rewords it differently but that is more concise than your original patch, that'd be great. [2007-02-25 04:39:27] danielc at analysisandsolutions dot com Hi David: Please switch back to backward in the phrase for back compatibility. In addition, I feel the reworded explanation that got committed is just juggling around the old explanation. While this is clearer, it's not crystal clear. [2007-02-24 21:10:08] [EMAIL PROTECTED] Your description in the patch was a little too verbose so I have reworded it myself. [2007-02-17 18:16:59] danielc at analysisandsolutions dot com Description: The note for the encoding parameter in the mb-strrpos documentation is ambiguous to me. It can be mistakenly interpreted as meaning that the parameter was added in 5.2 when in reality it's behavior was modified. http://www.analysisandsolutions.com/php/mb-strrpos.encoding.explanation.diff -- Edit this bug report at http://bugs.php.net/?id=40522edit=1
[PHP-DOC] #40522 [Opn]: PATCH: reword encoding param note in mb-strrpos
ID: 40522 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: A less wordy patch: http://www.analysisandsolutions.com/php/ mb-strrpos.encoding.explanation.v2.diff Previous Comments: [2007-02-25 14:19:03] danielc at analysisandsolutions dot com There is no such term as back compatibility in computer parlance. The term is backward compatibility or backwards compatibility: Google Hits phpdoc grep back: 71,100 1* backward: 1,130,000 7 backwards: 1,160,000 8 * Your entry. [2007-02-25 10:50:23] [EMAIL PROTECTED] I don't feel the change back to backward is necessary. If you wish to submit a patch that rewords it differently but that is more concise than your original patch, that'd be great. [2007-02-25 04:39:27] danielc at analysisandsolutions dot com Hi David: Please switch back to backward in the phrase for back compatibility. In addition, I feel the reworded explanation that got committed is just juggling around the old explanation. While this is clearer, it's not crystal clear. [2007-02-24 21:10:08] [EMAIL PROTECTED] Your description in the patch was a little too verbose so I have reworded it myself. [2007-02-17 18:16:59] danielc at analysisandsolutions dot com Description: The note for the encoding parameter in the mb-strrpos documentation is ambiguous to me. It can be mistakenly interpreted as meaning that the parameter was added in 5.2 when in reality it's behavior was modified. http://www.analysisandsolutions.com/php/mb-strrpos.encoding.explanation.diff -- Edit this bug report at http://bugs.php.net/?id=40522edit=1
[PHP-DOC] #40520 [Csd-Opn]: PATCH: wrong id in migration5.xml
ID: 40520 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Closed +Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Hi David: The name of the file and the id in the root element is migration5. The standard is to use that as the base of all id's throughout the document. So how is using migrating5 in the errorrep id not a bug? Previous Comments: [2007-02-24 21:20:16] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2007-02-17 18:10:46] danielc at analysisandsolutions dot com Description: Error Reporting section has incorrect id attribute. http://www.analysisandsolutions.com/php/migration5.id.diff -- Edit this bug report at http://bugs.php.net/?id=40520edit=1
[PHP-DOC] #40522 [Csd-Opn]: PATCH: reword encoding param note in mb-strrpos
ID: 40522 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Closed +Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Hi David: Please switch back to backward in the phrase for back compatibility. In addition, I feel the reworded explanation that got committed is just juggling around the old explanation. While this is clearer, it's not crystal clear. Previous Comments: [2007-02-24 21:10:08] [EMAIL PROTECTED] Your description in the patch was a little too verbose so I have reworded it myself. [2007-02-17 18:16:59] danielc at analysisandsolutions dot com Description: The note for the encoding parameter in the mb-strrpos documentation is ambiguous to me. It can be mistakenly interpreted as meaning that the parameter was added in 5.2 when in reality it's behavior was modified. http://www.analysisandsolutions.com/php/mb-strrpos.encoding.explanation.diff -- Edit this bug report at http://bugs.php.net/?id=40522edit=1
[PHP-DOC] #40519 [NEW]: Migrating from PHP 5.1 to PHP 5.2
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Migrating from PHP 5.1 to PHP 5.2 Description: Appendix entry for migrating to PHP 5.2 http://www.analysisandsolutions.com/php/migration52.xml -- Edit bug report at http://bugs.php.net/?id=40519edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40519r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40519r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40519r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40519r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40519r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40519r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40519r=needscript Try newer version:http://bugs.php.net/fix.php?id=40519r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40519r=support Expected behavior:http://bugs.php.net/fix.php?id=40519r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40519r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40519r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40519r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40519r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40519r=dst IIS Stability:http://bugs.php.net/fix.php?id=40519r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40519r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40519r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40519r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40519r=mysqlcfg
[PHP-DOC] #40520 [NEW]: PATCH: wrong id in migration5.xml
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: wrong id in migration5.xml Description: Error Reporting section has incorrect id attribute. http://www.analysisandsolutions.com/php/migration5.id.diff -- Edit bug report at http://bugs.php.net/?id=40520edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40520r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40520r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40520r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40520r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40520r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40520r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40520r=needscript Try newer version:http://bugs.php.net/fix.php?id=40520r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40520r=support Expected behavior:http://bugs.php.net/fix.php?id=40520r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40520r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40520r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40520r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40520r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40520r=dst IIS Stability:http://bugs.php.net/fix.php?id=40520r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40520r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40520r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40520r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40520r=mysqlcfg
[PHP-DOC] #40521 [NEW]: PATCH: new ini directives in 5.2
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: new ini directives in 5.2 Description: Patch for ini appendix with directives added in 5.2: http://www.analysisandsolutions.com/php/ini.add.52.diff -- Edit bug report at http://bugs.php.net/?id=40521edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40521r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40521r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40521r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40521r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40521r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40521r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40521r=needscript Try newer version:http://bugs.php.net/fix.php?id=40521r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40521r=support Expected behavior:http://bugs.php.net/fix.php?id=40521r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40521r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40521r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40521r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40521r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40521r=dst IIS Stability:http://bugs.php.net/fix.php?id=40521r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40521r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40521r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40521r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40521r=mysqlcfg
[PHP-DOC] #40522 [NEW]: PATCH: reword encoding param note in mb-strrpos
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: reword encoding param note in mb-strrpos Description: The note for the encoding parameter in the mb-strrpos documentation is ambiguous to me. It can be mistakenly interpreted as meaning that the parameter was added in 5.2 when in reality it's behavior was modified. http://www.analysisandsolutions.com/php/mb-strrpos.encoding.explanation.diff -- Edit bug report at http://bugs.php.net/?id=40522edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40522r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40522r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40522r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40522r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40522r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40522r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40522r=needscript Try newer version:http://bugs.php.net/fix.php?id=40522r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40522r=support Expected behavior:http://bugs.php.net/fix.php?id=40522r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40522r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40522r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40522r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40522r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40522r=dst IIS Stability:http://bugs.php.net/fix.php?id=40522r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40522r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40522r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40522r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40522r=mysqlcfg
[PHP-DOC] #40523 [NEW]: PATCH: various new parameters in 5.2
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: various new parameters in 5.2 Description: There are a few parameters added in PHP 5.2 have not been documented yet. Here's a patch adding them to the function signatures. While we'll still need to get someone to add the explanation for these parameters, this is a start and an indicator of what's needed. http://www.analysisandsolutions.com/php/parameters.52.diff -- Edit bug report at http://bugs.php.net/?id=40523edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40523r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40523r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40523r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40523r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40523r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40523r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40523r=needscript Try newer version:http://bugs.php.net/fix.php?id=40523r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40523r=support Expected behavior:http://bugs.php.net/fix.php?id=40523r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40523r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40523r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40523r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40523r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40523r=dst IIS Stability:http://bugs.php.net/fix.php?id=40523r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40523r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40523r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40523r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40523r=mysqlcfg
[PHP-DOC] #40519 [Opn]: Migrating from PHP 5.1 to PHP 5.2
ID: 40519 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: I updated the file a moment ago to fix some XML errors. Previous Comments: [2007-02-17 18:08:43] danielc at analysisandsolutions dot com Description: Appendix entry for migrating to PHP 5.2 http://www.analysisandsolutions.com/php/migration52.xml -- Edit this bug report at http://bugs.php.net/?id=40519edit=1
[PHP-DOC] #40525 [NEW]: PATCH: building libjpeg with enable-shared required
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: building libjpeg with enable-shared required Description: Patch to explain options PHP needs when building libjpeg: http://www.analysisandsolutions.com/php/image.jpeg.option.diff -- Edit bug report at http://bugs.php.net/?id=40525edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40525r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40525r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40525r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40525r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40525r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40525r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40525r=needscript Try newer version:http://bugs.php.net/fix.php?id=40525r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40525r=support Expected behavior:http://bugs.php.net/fix.php?id=40525r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40525r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40525r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40525r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40525r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40525r=dst IIS Stability:http://bugs.php.net/fix.php?id=40525r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40525r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40525r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40525r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40525r=mysqlcfg
[PHP-DOC] #32016 [NEW]: msql_fetch*() updates
From: danielc at analysisandsolutions dot com Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: msql_fetch*() updates Description: Below is a link to a patch for the various msql_fetch*() functions. The main point of these updates is to make note of the behavioral changes in PHP 4.3.11 and 5.0.4. While I was at it, I added examples and fixed some other errors. http://www.analysisandsolutions.com/php/msql.docs.diff Commit message: * Add warning about fixing NULL value bug #31960. * Fix some return and parameter data types. * Add result_type parameter to fetch_object() synopsis. * Add some items to See Also. -- Edit bug report at http://bugs.php.net/?id=32016edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32016r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32016r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32016r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32016r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32016r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32016r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32016r=needscript Try newer version: http://bugs.php.net/fix.php?id=32016r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32016r=support Expected behavior: http://bugs.php.net/fix.php?id=32016r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32016r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32016r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32016r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32016r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32016r=dst IIS Stability: http://bugs.php.net/fix.php?id=32016r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32016r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32016r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32016r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32016r=mysqlcfg
[PHP-DOC] #30955 [Opn]: PATCH: setting TEMP so SQLite will work on Windows
ID: 30955 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: Irrelevant New Comment: Can someone please apply the patch? Previous Comments: [2004-12-29 20:43:57] danielc at analysisandsolutions dot com Nicely put nlopess. By the way, I've tweaked the patch in the last few minutes. So, if it gets used, please obtain a fresh copy from the URI, above. [2004-12-29 20:25:28] [EMAIL PROTECTED] I've checked libsqlite code. It is using GetTempPath() on windows to get a temporary file. (http://msdn.microsoft.com/library/en-us/fileio/base/gettemppath.asp) According to MSDN docs the order is: 1. The path specified by the TMP environment variable. 2. The path specified by the TEMP environment variable. 3. The path specified by the USERPROFILE environment variable. 4. The Windows directory. So, I think this should be documented. [2004-12-29 18:02:01] [EMAIL PROTECTED] Isn't this more a SQLLite problem than a documentation problem/PHP Problem? [2004-12-02 22:47:46] danielc at analysisandsolutions dot com I'm talking about Windows 2000 Pro and XP Pro. TEMP _might_ be set if the web server is running under the SYSTEM account. But if the web server service is running under an unprivilged user account TEMP isn't automatically available. If TEMP isn't set, the sqlite extension goes to write the temporary files into the windows directory. Not a good idea. [2004-12-02 18:59:53] [EMAIL PROTECTED] But windows *always* set the TEMP var by default, doesn't it? I never had such problems on windows... To which version of windows are you refering to? Windows 9x? 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/30955 -- Edit this bug report at http://bugs.php.net/?id=30955edit=1
[PHP-DOC] #31978 [NEW]: msql_fetch_field() doesn't produce primary_key property
From: danielc at analysisandsolutions dot com Operating system: NetBSD 2.0 PHP version: 5CVS-2005-02-15 (dev) PHP Bug Type: Documentation problem Bug description: msql_fetch_field() doesn't produce primary_key property Description: The documentation at http://php.net/msql_fetch_field says the output of msql_fetch_field() includes a property named primary_key. But mSQL does not have primary keys nor is this property created in the object created by this function. Please remove the primary_key property from the docs. -- Edit bug report at http://bugs.php.net/?id=31978edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31978r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31978r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31978r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31978r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31978r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31978r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31978r=needscript Try newer version: http://bugs.php.net/fix.php?id=31978r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31978r=support Expected behavior: http://bugs.php.net/fix.php?id=31978r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31978r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31978r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31978r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31978r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31978r=dst IIS Stability: http://bugs.php.net/fix.php?id=31978r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31978r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31978r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31978r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31978r=mysqlcfg
[PHP-DOC] #31959 [NEW]: msql_error() does not take a parameter
From: danielc at analysisandsolutions dot com Operating system: Irrelevant PHP version: 5CVS-2005-02-13 (dev) PHP Bug Type: Documentation problem Bug description: msql_error() does not take a parameter Description: http://php.net/msql_error says the funciton takes a parameter. It does not. See http://cvs.php.net/annotate.php/php-src/ext/msql/php_msql.c?rev=1.58#478 to confirm. Thanks. -- Edit bug report at http://bugs.php.net/?id=31959edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31959r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31959r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31959r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31959r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31959r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31959r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31959r=needscript Try newer version: http://bugs.php.net/fix.php?id=31959r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31959r=support Expected behavior: http://bugs.php.net/fix.php?id=31959r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31959r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31959r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31959r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31959r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31959r=dst IIS Stability: http://bugs.php.net/fix.php?id=31959r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31959r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31959r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31959r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31959r=mysqlcfg
[PHP-DOC] #31951 [NEW]: msql_connect() has 0 or 1 parameters
From: danielc at analysisandsolutions dot com Operating system: Irrelevant PHP version: 5CVS-2005-02-13 (dev) PHP Bug Type: Documentation problem Bug description: msql_connect() has 0 or 1 parameters Description: http://php.net/msql_connect is wrong. msql_connect() accepts 0 or 1 parameters. See http://cvs.php.net/annotate.php/php-src/ext/msql/php_msql.c?rev=1.58#239 to confirm. So, please remove the username and password parameters. While y'all are at it, please incorporate the user note on that page regarding Unix sockets being used if the hostname parameter is not provided. Thanks. -- Edit bug report at http://bugs.php.net/?id=31951edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31951r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31951r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31951r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31951r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31951r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31951r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31951r=needscript Try newer version: http://bugs.php.net/fix.php?id=31951r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31951r=support Expected behavior: http://bugs.php.net/fix.php?id=31951r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31951r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31951r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31951r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31951r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31951r=dst IIS Stability: http://bugs.php.net/fix.php?id=31951r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31951r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31951r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31951r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31951r=mysqlcfg
[PHP-DOC] #30955 [Opn]: PATCH: setting TEMP so SQLite will work on Windows
ID: 30955 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: Irrelevant New Comment: Nicely put nlopess. By the way, I've tweaked the patch in the last few minutes. So, if it gets used, please obtain a fresh copy from the URI, above. Previous Comments: [2004-12-29 20:25:28] [EMAIL PROTECTED] I've checked libsqlite code. It is using GetTempPath() on windows to get a temporary file. (http://msdn.microsoft.com/library/en-us/fileio/base/gettemppath.asp) According to MSDN docs the order is: 1. The path specified by the TMP environment variable. 2. The path specified by the TEMP environment variable. 3. The path specified by the USERPROFILE environment variable. 4. The Windows directory. So, I think this should be documented. [2004-12-29 18:02:01] [EMAIL PROTECTED] Isn't this more a SQLLite problem than a documentation problem/PHP Problem? [2004-12-02 22:47:46] danielc at analysisandsolutions dot com I'm talking about Windows 2000 Pro and XP Pro. TEMP _might_ be set if the web server is running under the SYSTEM account. But if the web server service is running under an unprivilged user account TEMP isn't automatically available. If TEMP isn't set, the sqlite extension goes to write the temporary files into the windows directory. Not a good idea. [2004-12-02 18:59:53] [EMAIL PROTECTED] But windows *always* set the TEMP var by default, doesn't it? I never had such problems on windows... To which version of windows are you refering to? Windows 9x? [2004-12-02 02:45:47] danielc at analysisandsolutions dot com Description: If the TEMP environment variable isn't set and the computer in question has some semblance of security, the following error comes up: malformed database schema - unable to open a temporary database file for storing temporary tables This is a common problem that has been asked in various forums. Here is a documentation patch to explain what needs to be done in order to get SQLite to work on secure Windows machines: http://www.analysisandsolutions.com/php/sqlitetemp.diff Thanks. -- Edit this bug report at http://bugs.php.net/?id=30955edit=1
[PHP-DOC] #30955 [Fbk-Opn]: PATCH: setting TEMP so SQLite will work on Windows
ID: 30955 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: Irrelevant New Comment: I'm talking about Windows 2000 Pro and XP Pro. TEMP _might_ be set if the web server is running under the SYSTEM account. But if the web server service is running under an unprivilged user account TEMP isn't automatically available. If TEMP isn't set, the sqlite extension goes to write the temporary files into the windows directory. Not a good idea. Previous Comments: [2004-12-02 18:59:53] [EMAIL PROTECTED] But windows *always* set the TEMP var by default, doesn't it? I never had such problems on windows... To which version of windows are you refering to? Windows 9x? [2004-12-02 02:45:47] danielc at analysisandsolutions dot com Description: If the TEMP environment variable isn't set and the computer in question has some semblance of security, the following error comes up: malformed database schema - unable to open a temporary database file for storing temporary tables This is a common problem that has been asked in various forums. Here is a documentation patch to explain what needs to be done in order to get SQLite to work on secure Windows machines: http://www.analysisandsolutions.com/php/sqlitetemp.diff Thanks. -- Edit this bug report at http://bugs.php.net/?id=30955edit=1
[PHP-DOC] #30955 [NEW]: PATCH: setting TEMP so SQLite will work on Windows
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: PATCH: setting TEMP so SQLite will work on Windows Description: If the TEMP environment variable isn't set and the computer in question has some semblance of security, the following error comes up: malformed database schema - unable to open a temporary database file for storing temporary tables This is a common problem that has been asked in various forums. Here is a documentation patch to explain what needs to be done in order to get SQLite to work on secure Windows machines: http://www.analysisandsolutions.com/php/sqlitetemp.diff Thanks. -- Edit bug report at http://bugs.php.net/?id=30955edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30955r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30955r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30955r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30955r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30955r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30955r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30955r=needscript Try newer version: http://bugs.php.net/fix.php?id=30955r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30955r=support Expected behavior: http://bugs.php.net/fix.php?id=30955r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30955r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30955r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30955r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30955r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30955r=dst IIS Stability: http://bugs.php.net/fix.php?id=30955r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30955r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30955r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30955r=mysqlcfg
[PHP-DOC] #28912 [Csd]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
ID: 28912 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Closed Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: If anyone wonders about the second example returning 253/MYSQLI_TYPE_VAR_STRING for the CHAR column, it's due to silent column changes by MySQL: if a table contains any variable-length columns... all CHAR columns longer than three characters are changed to VARCHAR columns. http://dev.mysql.com/doc/mysql/en/Silent_column_changes.html Previous Comments: [2004-06-29 07:50:48] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2004-06-29 01:37:12] danielc at analysisandsolutions dot com Ah. Thanks for the clarification. Then phpdoc/en/reference/mysqli/constants.xml needs updating. You said: varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. Though the docs say: MYSQLI_TYPE_STRING (integer) Field is defined as VARCHAR MYSQLI_TYPE_CHAR (integer) Field is defined as CHAR BUT, not so fast... CHAR columns return 253, but MYSQLI_TYPE_STRING's value is 254. And MYSQLI_TYPE_CHAR is defined, but what's it for? ?php mysqli_query($db-connection, 'CREATE TABLE bar (Vf VARCHAR(5),' . ' Cf CHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Vf, Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_VAR_STRING = ' . MYSQLI_TYPE_VAR_STRING . \n\n; $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n\n; echo So, what's this for?...\n; echo 'MYSQLI_TYPE_CHAR = ' . MYSQLI_TYPE_CHAR . \n; mysqli_query($db-connection, 'DROP TABLE bar'); ? vvv OUTPUT Vf type found = 253 MYSQLI_TYPE_VAR_STRING = 253 Cf type found = 253 MYSQLI_TYPE_STRING = 254 So, what's this for?... MYSQLI_TYPE_CHAR = 1 ^^^ [2004-06-28 23:48:20] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. [2004-06-28 19:35:22] danielc at analysisandsolutions dot com Documentation isn't involved. This is purely code. The type property returned from the function != the value of the constant. Perhaps your getting the right result is due to both of us running different versions of the software? Here's what I'm on: MySQL: Ver 14.5 Distrib 4.1.2-alpha, for Win95/Win98 (i32) PHP:PHP 5.0.0-dev (cli) (built: Jun 28 2004 16:29:27) [2004-06-28 18:51:13] [EMAIL PROTECTED] Looks like a documentation problem. However I couldn't find this in documentation. Also the example output in mysqli_fetch_field returns 254. Could you please give me a link to the wrong documentation? 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/28912 -- Edit this bug report at http://bugs.php.net/?id=28912edit=1
[PHP-DOC] #26517 [Opn]: link_identifier clearer as transaction_identifier
ID: 26517 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Hmmm... I now see that the docs say the link argument can be a connection id or a transaction id. The reason I posted the bug was my test code didn't work properly when a connection id was used. I will test further and report back. Previous Comments: [2003-12-04 00:17:04] danielc at analysisandsolutions dot com This also applies to function.ibase-rollback.php and function.ibase-rollback-ret.php [2003-12-04 00:14:45] danielc at analysisandsolutions dot com Description: In function.ibase-commit.php, the call definition says bool ibase_commit ( [resource link_identifier]) It would be clearer to say bool ibase_commit ( [resource transaction_identifier]) because link_identifier could be misconstrued to mean the database connection identifier. -- Edit this bug report at http://bugs.php.net/?id=26517edit=1
[PHP-DOC] #26517 [NEW]: link_identifier clearer as transaction_identifier
From: danielc at analysisandsolutions dot com Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: link_identifier clearer as transaction_identifier Description: In function.ibase-commit.php, the call definition says bool ibase_commit ( [resource link_identifier]) It would be clearer to say bool ibase_commit ( [resource transaction_identifier]) because link_identifier could be misconstrued to mean the database connection identifier. -- Edit bug report at http://bugs.php.net/?id=26517edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26517r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26517r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26517r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26517r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26517r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26517r=needscript Try newer version: http://bugs.php.net/fix.php?id=26517r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26517r=support Expected behavior: http://bugs.php.net/fix.php?id=26517r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26517r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26517r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26517r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26517r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26517r=dst IIS Stability: http://bugs.php.net/fix.php?id=26517r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26517r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26517r=float
[PHP-DOC] #26517 [Opn]: link_identifier clearer as transaction_identifier
ID: 26517 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This also applies to function.ibase-rollback.php and function.ibase-rollback-ret.php Previous Comments: [2003-12-04 00:14:45] danielc at analysisandsolutions dot com Description: In function.ibase-commit.php, the call definition says bool ibase_commit ( [resource link_identifier]) It would be clearer to say bool ibase_commit ( [resource transaction_identifier]) because link_identifier could be misconstrued to mean the database connection identifier. -- Edit this bug report at http://bugs.php.net/?id=26517edit=1
[PHP-DOC] #24970 [NEW]: install.windows.php
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: install.windows.php Description: Hi Folks: I would like to strongly urge install.windows.php be changed in regards to how DLL's and paths are handled. The current recommendations say users should move the various needed DLLs into a location that's within the path, like c:\winnt\system32. This is cumbersome and prone to error, particularly when upgrading. The FAR simpler solution is to change the path itself. All one needs to do is add ;c:\php;c:\php\dlls to the end of one's path statement and you're good to go! Now, one can switch between PHP versions just by moving the old installation into a different directory and unziping the new version into c:\php. This is what I've done on my system and it works great. Thanks, --Dan -- Edit bug report at http://bugs.php.net/?id=24970edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24970r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24970r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24970r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24970r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24970r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24970r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24970r=support Expected behavior: http://bugs.php.net/fix.php?id=24970r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24970r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24970r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24970r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24970r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24970r=dst IIS Stability: http://bugs.php.net/fix.php?id=24970r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24970r=gnused -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DOC] #24970 [Opn]: install.windows.php: tell users to change path, not file locations
ID: 24970 User updated by: danielc at analysisandsolutions dot com -Summary: install.windows.php Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: Irrelevant New Comment: Changed Summary. Previous Comments: [2003-08-07 02:26:36] danielc at analysisandsolutions dot com Description: Hi Folks: I would like to strongly urge install.windows.php be changed in regards to how DLL's and paths are handled. The current recommendations say users should move the various needed DLLs into a location that's within the path, like c:\winnt\system32. This is cumbersome and prone to error, particularly when upgrading. The FAR simpler solution is to change the path itself. All one needs to do is add ;c:\php;c:\php\dlls to the end of one's path statement and you're good to go! Now, one can switch between PHP versions just by moving the old installation into a different directory and unziping the new version into c:\php. This is what I've done on my system and it works great. Thanks, --Dan -- Edit this bug report at http://bugs.php.net/?id=24970edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
