#21783 [NEW]: cli execution doesn't find php.ini
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0
PHP version: 4.3.0
PHP Bug Type: *Configuration Issues
Bug description: cli execution doesn't find php.ini
Hi:
Please pardon the initial background if it's irrelevant, but I figured it
may come into play somehow...
Been using PHP for years, just fine. It's installed in f:\progra~1\php.
That dir is in my Path, so I keep the php.ini and various dll's there to
make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup directory
and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . "\n";
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . "\n";
Now I open up command line window and execute:
> cd progra~1\php
> php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
> cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one directory
level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit bug report at http://bugs.php.net/?id=21783&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21783&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21783&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21783&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21783&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21783&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21783&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21783&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21783&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21783&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21783&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21783&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21783&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21783&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21783&r=gnused
#21783 [WFx]: cli execution doesn't find php.ini
ID: 21783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Wont fix
Bug Type: *Configuration Issues
Operating System: Windows NT 4.0
PHP Version: 4.3.0
New Comment:
Okay. Then, can you please change this into a documentation bug? The
features.commandline.php pages should really explain this.
For the clarity of other people reading this, the simple, long-term
solution is creating an environment variable named PHPRC and setting it
to the path of where your php.ini file resides. For example,
"c:\progra~1\php"
Thanks,
--Dan
Previous Comments:
[2003-01-20 19:05:54] [EMAIL PROTECTED]
This is how cli is designed to work (not to look for php.ini in the
current working directory) and it won't change.
You can achieve the desired behaviour by issuing:
set PHPRC=.
on the command line, or setting this environmental variable elsewhere
in the system.
[2003-01-20 17:29:50] [EMAIL PROTECTED]
Hi:
Please pardon the initial background if it's irrelevant, but I figured
it may come into play somehow...
Been using PHP for years, just fine. It's installed in
f:\progra~1\php. That dir is in my Path, so I keep the php.ini and
various dll's there to make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup
directory and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . "\n";
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . "\n";
Now I open up command line window and execute:
> cd progra~1\php
> php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
> cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one
directory level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit this bug report at http://bugs.php.net/?id=21783&edit=1
#21783 [WFx]: cli execution doesn't find php.ini
ID: 21783
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Wont fix
Bug Type: *Configuration Issues
Operating System: Windows NT 4.0
PHP Version: 4.3.0
New Comment:
Thank you for that link. None the less, people reading the
features.commandline.php won't necessarily read the configuration.php
page.
Gee, take me for example! :) I spent a significant amount of time
trying to figure out what was going on. Checked the command line page
in the manual, all of the user comments, the newsgroup archives and the
bug database. All of which turned up nothing, hence my bug report.
So, a simple mention of the situation and a cross reference link to
configuration.php would be helpful.
Heck, I'm fairly PHP literate and a good sleuth, but wound up using
your time anyway. This minor documentation tweak will save everyone
grief in the long run.
Of course, I could add a user comment, but that doesn't have the same
impact.
Thanks for your consideration,
--Dan
Previous Comments:
[2003-01-20 19:51:29] [EMAIL PROTECTED]
PHPRC environmental variable (and other ways of finding it) are
documented at:
http://www.php.net/manual/en/configuration.php#configuration.file
[2003-01-20 19:44:22] [EMAIL PROTECTED]
Okay. Then, can you please change this into a documentation bug? The
features.commandline.php pages should really explain this.
For the clarity of other people reading this, the simple, long-term
solution is creating an environment variable named PHPRC and setting it
to the path of where your php.ini file resides. For example,
"c:\progra~1\php"
Thanks,
--Dan
[2003-01-20 19:05:54] [EMAIL PROTECTED]
This is how cli is designed to work (not to look for php.ini in the
current working directory) and it won't change.
You can achieve the desired behaviour by issuing:
set PHPRC=.
on the command line, or setting this environmental variable elsewhere
in the system.
[2003-01-20 17:29:50] [EMAIL PROTECTED]
Hi:
Please pardon the initial background if it's irrelevant, but I figured
it may come into play somehow...
Been using PHP for years, just fine. It's installed in
f:\progra~1\php. That dir is in my Path, so I keep the php.ini and
various dll's there to make upgrading easy.
Installed latest version, 4.3.0, by moving old version to backup
directory and unzipping binaries into f:\progra~1\php.
Edited php.ini to my tastes.
After running into problems with CLI not finding my php.ini file, I ran
some tests. The test script contains:
echo 'include_path... ' . ini_get('include_path') . "\n";
echo 'cfg_file_path... ' . get_cfg_var('cfg_file_path') . "\n";
Now I open up command line window and execute:
> cd progra~1\php
> php ./script
Has the right output:
include_path... .;f:\progra~1\pear
cfg_file_path... F:\PROGRA~1\php\php.ini
But, running the CLI does not:
> cli\php ./script
include_path... .;c:\php4\pear
cfg_file_path...
If I copy php.ini to the cli directory, the expected results are
obtained.
One assumes the CLI version would be smart enough to look up one
directory level or in the Path for the php.ini.
Of course, I can specify the config file via the -c flag, but that's
awkward for general use and is counter-intuitive.
I hope the behavior of the CLI executable will be changed accordingly,
please.
Thanks,
--Dan
--
Edit this bug report at http://bugs.php.net/?id=21783&edit=1
Bug #7160 Updated: Bad escape sequence not being reported
ID: 7160 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: *General Issues Operating System: NT 4.0 SP 6a -PHP Version: 4.0.3 +PHP Version: 4.1.1 New Comment: In PHP 4.1.1 No warning reported even if php.ini has error_reporting = E_ALL or error_reporting = E_NOTICE Warning reported if the script has error_reporting(E_ALL); or error_reporting(E_NOTICE); Previous Comments: [2000-11-27 11:11:10] [EMAIL PROTECTED] Check your error_reporting line in php.ini or try setting the error level to highest in the beginning of the script: error_reporting(E_ALL); --Jani [2000-10-12 09:46:04] [EMAIL PROTECTED] $X = "c:\dirname"; In PHP 3.0.11, that's reported as "Bad escape sequence." In PHP 4.0.3, no error is reported. -- Edit this bug report at http://bugs.php.net/?id=7160&edit=1
#26206 [Opn->Dup]: argv and argc not defined
ID: 26206
Updated by: [EMAIL PROTECTED]
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Duplicate
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
In the current thread, Jani pointed out that this is related to bug
25724 -- http://bugs.php.net/bug.php?id=25724 -- which
says that when register_long_arrays is off, the superglobals are
broken.
So, until that bug is fixed, turn register_long_arrays = On in php.ini
to get $_SERVER['argv'] and $_SERVER['argc'] to work.
Previous Comments:
[2004-01-17 19:44:43] danielc at analysisandsolutions dot com
Here's a link to the discussion on the interals list back in October
about these changes:
http://marc.theaimsgroup.com/?t=10650930736&r=1&w=2
This is a link to the current discussion regarding the situation and
how either I'm misunderstanding things or things may not be working as
expected:
http://marc.theaimsgroup.com/?t=10743658311&r=1&w=2
--------
[2004-01-17 14:17:35] danielc at analysisandsolutions dot com
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
INVOCATION:
C:\PROGRA~1\php>php argvtest.php 1 2
OUTPUT:
array(3) {
[0]=>
string(12) "argvtest.php"
[1]=>
string(1) "1"
[2]=>
string(1) "2"
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
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/26206
--
Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#30690 [Bgs->Opn]: Resource handle from ibase_execute becomes invalid after return
ID: 30690
Updated by: [EMAIL PROTECTED]
Reported By: kobaz at kobaz dot net
-Status: Bogus
+Status: Open
Bug Type: InterBase related
Operating System: Linux 2.6.5
PHP Version: 4.3.9
New Comment:
While this behavior may be intentional on your part, I strongly request
it be changed.
1) No other DBMS extension in PHP does this.
2) This makes writing programs using ibase very difficult.
3) This makes it impossible to write abstraction packages, such as PEAR
DB (which I'm the lead of).
Previous Comments:
[2004-11-07 14:21:36] [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
When $prepare goes out of scope, it is cleaned up along with all the
resources that depend on it. That includes any results that it
created.
[2004-11-05 02:16:40] kobaz at kobaz dot net
Description:
Resource handle from ibase_execute becomes invalid after return
Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');
function DB_PQuery ($sql, $data) {
global $conn;
$prepare = ibase_prepare($conn, $sql);
$result = ibase_execute($prepare, $data);
//$A = ibase_fetch_assoc($result); // uncommenting this will
show resource is valid here
//print_r($A);
// after this function returns, the return value is no longer a valid
resource
return $result;
}
$result = DB_PQuery("SELECT * FROM testing WHERE a = ?", '1');
$A = ibase_fetch_assoc($result); // fails with: invalid statement
handle
print_r($A);
Expected result:
The ibase_fetch_assoc should be successful after DB_PQuery returns.
Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can
be used with ibase_fetch_assoc successfully.
After DB_PQuery returns, the return value is not a valid resource
handle despite that nothing in the script has modified it.
--
Edit this bug report at http://bugs.php.net/?id=30690&edit=1
Bug #60467 [Opn]: About 107 auto test [phpt script] failed .
Edit report at https://bugs.php.net/bug.php?id=60467&edit=1 ID: 60467 Updated by: dani...@php.net Reported by:Jtang at suse dot com Summary:About 107 auto test [phpt script] failed . Status: Open Type: Bug Package:Testing related Operating System: SLES 11 SP2 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I'll deal with the ext/date/tests portions in the near future. Previous Comments: [2011-12-08 03:34:59] Jtang at suse dot com Description: I use the phpt file from php 5.3 tarball package for automation test. 11338 test file , 107 failed , in 107 failed : # 33 test are expect as described in output # 9 test have bug NO. # 66 test is failed 66 test cases are: ./ext/calendar/tests/easter_date.phpt ./ext/calendar/tests/unixtojd.phpt ./ext/date/tests/DateTime_days-spring-type2-type2.phpt ./ext/date/tests/DateTime_days-spring-type2-type3.phpt ./ext/date/tests/DateTime_days-spring-type3-type2.phpt ./ext/date/tests/DateTime_days-spring-type3-type3.phpt ./ext/date/tests/DateTime_sub-dates.phpt ./ext/date/tests/DateTime_sub-february.phpt ./ext/date/tests/timezone_location_get.phpt ./ext/dom/tests/DOMDocument_relaxNGValidate_error2.phpt ./ext/dom/tests/DOMDocument_validate_on_parse_variation.phpt ./ext/gmp/tests/gmp_nextprime.phpt ./ext/intl/tests/resourcebundle_arrayaccess.phpt ./ext/intl/tests/resourcebundle_individual.phpt ./ext/intl/tests/resourcebundle_iterator.phpt ./ext/mysql/tests/001.phpt ./ext/mysql/tests/mysql_connect.phpt ./ext/mysql/tests/mysql_max_links.phpt ./ext/mysql/tests/mysql_sql_safe_mode.phpt ./ext/mysqli/tests/mysqli_connect.phpt ./ext/mysqli/tests/mysqli_connect_oo.phpt ./ext/mysqli/tests/mysqli_connect_oo_defaults.phpt ./ext/pcre/tests/006.phpt ./ext/pdo_mysql/tests/pdo_mysql___construct_options.phpt ./ext/pdo_mysql/tests/pdo_mysql_interface.phpt ./ext/posix/tests/posix_ttyname_error.phpt ./ext/posix/tests/posix_ttyname_variation1.phpt ./ext/posix/tests/posix_ttyname_variation2.phpt ./ext/posix/tests/posix_ttyname_variation3.phpt ./ext/posix/tests/posix_ttyname_variation4.phpt ./ext/posix/tests/posix_ttyname_variation5.phpt ./ext/posix/tests/posix_ttyname_variation6.phpt ./ext/posix/tests/posix_ttyname_variation7.phpt ./ext/session/tests/014.phpt ./ext/session/tests/015.phpt ./ext/session/tests/018.phpt ./ext/session/tests/020.phpt ./ext/session/tests/021.phpt ./ext/session/tests/session_id_variation2.phpt ./ext/sockets/tests/socket_strerror.phpt ./ext/spl/examples/tests/dualiterator_001.phpt ./ext/sqlite/tests/sqlite_session_001.phpt ./ext/sqlite/tests/sqlite_session_002.phpt ./ext/sqlite3/tests/sqlite3_prepare_001.phpt ./ext/standard/tests/class_object/is_a_error_001.phpt ./ext/standard/tests/class_object/is_subclass_of_error_001.phpt ./ext/standard/tests/general_functions/getservbyname_variation10.phpt ./ext/standard/tests/general_functions/getservbyname_variation9.phpt ./ext/standard/tests/general_functions/getservbyport_variation1.phpt ./ext/standard/tests/general_functions/phpinfo.phpt ./ext/standard/tests/general_functions/proc_nice_variation5.phpt ./ext/standard/tests/misc/time_sleep_until_basic.phpt ./ext/standard/tests/php_ini_loaded_file.phpt ./ext/standard/tests/strings/htmlentities02.phpt ./ext/standard/tests/strings/htmlentities04.phpt ./ext/standard/tests/strings/htmlentities10.phpt ./ext/standard/tests/strings/htmlentities11.phpt ./ext/standard/tests/strings/htmlentities13.phpt ./ext/standard/tests/strings/htmlentities15.phpt ./ext/standard/tests/strings/setlocale_variation2.phpt ./ext/xsl/tests/xslt010.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcnostring.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcundef.phpt ./sapi/cli/tests/001.phpt ./sapi/cli/tests/015.phpt Test script: --- only one line script env TEST_PHP_EXECUTABLE=/usr/bin/php REPORT_EXIT_STATUS=1 TEST_PHP_SRCDIR=/usr/share/qa/qa_test_php53 TEST_PHP_DETAILED=1 NO_INTERACTION=1 /usr/bin/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/share/qa/qa_test_php53/run-tests.php [phpt.file] Expected result: 65 test cases should pass? Actual result: -- 65 test cases failed -- Edit this bug report at https://bugs.php.net/bug.php?id=60467&edit=1
Bug #60981 [Opn->Fbk]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981&edit=1 ID: 60981 Updated by: dani...@php.net Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests -Status: Open +Status: Feedback Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: The environment variables need to be established in a scope available all shell scripts. For example, them in the ~/.bashrc script of the user executing "make test". Set the variables in ~/.bashrc source ~/.bashrc make test The "source" step is only necessary in the first shell since the variables were not available when the shell was opened. All future shells will have them. Previous Comments: [2012-02-05 18:50:42] david at davidfavor dot com Description: Shell environment variables are not accessible via getenv() during tests. Test script: --- export MYSQL_TEST_PASSWD=... make test TESTS=ext/mysql*/tests/001.phpt Runs the mysql + mysqli connect tests and both are skipped. Tests are skipped showing... (using password: NO) Manually setting $passwd in connect.inc for both test sets runs all tests as expected. So MYSQL_TEST_PASSWD is ignored. -- Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1
#47629 [Bgs->Fbk]: mysqli connect timeout causes fatal error
ID: 47629
Updated by: dani...@php.net
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Feedback
Bug Type: MySQLi related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-12 (snap)
-Assigned To:
+Assigned To: pajoye
New Comment:
Yes, the execution timeout makes sense some ways. The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.
Previous Comments:
[2009-06-20 13:19:04] paj...@php.net
With:
max_execution_time: 2
default_socket_timeout: 6
It is the expected behavior to have a fatal error about the maximum
execution time being exceeded. max_execution_time has the highest
importance.
[2009-03-12 04:41:21] danielc at analysisandsolutions dot com
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11
2009 17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . "\n\n";
echo "ONE ---\n";
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
echo "TWO ---\n";
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit this bug report at http://bugs.php.net/?id=47629&edit=1
#49767 [Asn]: estrdup crash
ID: 49767
Updated by: dani...@php.net
Reported By: mb at smartftp dot com
Status: Assigned
Bug Type: Reproducible crash
Operating System: win32 only -Windows 2008 SP2 x86
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Bug #47627 marked duplicate of this.
Previous Comments:
[2009-10-04 19:35:54] mb at smartftp dot com
I have also sent you the crash report by email. Open the .mht file (RS
removed the .mth extension for some reason) with IE.
[2009-10-04 19:25:46] paj...@php.net
I corrected myself about the script by asking for the full bt (the one
on RS was not readable).
The diagnostic sounds good, I have to reproduce it to be sure. Assigned
to me.
[2009-10-04 17:28:20] mb at smartftp dot com
I don't think you need a script. A little bit of time and motivation
would do as well:
Please review your code:
File: main.c
PHPAPI int php_execute_script(zend_file_handle *primary_file
TSRMLS_DC)
{
...
#ifdef PHP_WIN32
UpdateIniFromRegistry(primary_file->filename TSRMLS_CC);
#endif
..
}
Then:
File: registry.c
void UpdateIniFromRegistry(char *path TSRMLS_DC)
{
-> BUG: missing check for argument
// here comes the check for Per Directory registry value. If it is not
found the function exists and never comes to the estrdup and hence no
crash.
...
orig_path = path = estrdup(path);
..
}
The problem only happens if the "Per Directory Values" registry key is
present. In this case estrdup(NULL) is called and you get the crash.
So I think the argument (path) should be checked for NULL. And when I
look at the main.c I also noticed that you sometimes expect the
primary_file->filename to be null, so maybe you add a check before the
UpdateIniFromRegistry() call.
Proposed FIX:
#ifdef PHP_WIN32
if(primary_file->filename)
{
UpdateIniFromRegistry(primary_file->filename TSRMLS_CC);
}
#endif
+ Add argument check for UpdateIniFromRegistry
Workaround:
Remove "Per Directories Values" registry key.
Regards,
Mat
[2009-10-04 17:23:34] paj...@php.net
Btw, can you also zip the report and send it to me or provide a link to
the zip (pls not one of these radidshare thing) :)
[2009-10-04 17:21:26] paj...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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/49767
--
Edit this bug report at http://bugs.php.net/?id=49767&edit=1
#43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: [EMAIL PROTECTED]
Reported By: losd at mail dot dk
Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
Assigned To: dmitry
New Comment:
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
Previous Comments:
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir("C:/Test/NoAccess/Access/Subdir/..");
[2008-01-11 12:23:54] losd at mail dot dk
Description:
If the parent directory of a Windows network share is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
--
Edit this bug report at http://bugs.php.net/?id=43817&edit=1
#43817 [Csd->Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: dani...@php.net
Reported By: losd at mail dot dk
-Status: Closed
+Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
Assigned To: dmitry
New Comment:
This problem still exists in 5.3.0 beta 1
(http://windows.php.net/downloads/qa/php-5.3.0beta1-Win32-VC6-x86.zip)
Previous Comments:
[2008-08-12 09:42:06] dmi...@php.net
Fixed in CVS HEAD and PHP_5_3.
[2008-03-01 09:09:15] losd at mail dot dk
Doh, sorry, thought I could edit the original text. Just delete that
comment.
But yes, as Daniel correctly points out, it's all Windows permission
handling (As my reproduce code also shows), not just related to network
shares... I experienced it in one at first, I guess that's why it stuck
in my brain.
[2008-03-01 09:02:02] losd at mail dot dk
Description:
If the parent directory of a Windows directory is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
[2008-03-01 01:10:46] dani...@php.net
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir("C:/Test/NoAccess/Access/Subdir/..");
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/43817
--
Edit this bug report at http://bugs.php.net/?id=43817&edit=1
#43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: dani...@php.net
Reported By: losd at mail dot dk
Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
-PHP Version: 5.2.5
+PHP Version: 5.3.0beta1
Assigned To: dmitry
New Comment:
Changing version from 5.2.5 to 5.3.0beta1 to facilitate this getting
fixed before the next release.
Previous Comments:
[2009-02-03 15:31:49] dani...@php.net
This problem still exists in 5.3.0 beta 1
(http://windows.php.net/downloads/qa/php-5.3.0beta1-Win32-VC6-x86.zip)
[2008-08-12 09:42:06] dmi...@php.net
Fixed in CVS HEAD and PHP_5_3.
[2008-03-01 09:09:15] losd at mail dot dk
Doh, sorry, thought I could edit the original text. Just delete that
comment.
But yes, as Daniel correctly points out, it's all Windows permission
handling (As my reproduce code also shows), not just related to network
shares... I experienced it in one at first, I guess that's why it stuck
in my brain.
[2008-03-01 09:02:02] losd at mail dot dk
Description:
If the parent directory of a Windows directory is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
[2008-03-01 01:10:46] dani...@php.net
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
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/43817
--
Edit this bug report at http://bugs.php.net/?id=43817&edit=1
#47543 [Bgs->Opn]: irrelevant warning message
ID: 47543
Updated by: dani...@php.net
Reported By: jeffreybolle at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Mail related
Operating System: Windows Vista SP1
PHP Version: 5.3.0beta1
-Assigned To:
+Assigned To: kalle
New Comment:
The php.ini-recommended and php.ini-dist in CVS need to have the
mail.log entries commented out by default.
Previous Comments:
[2009-03-02 15:45:51] jeffreybolle at gmail dot com
Hi Kalle,
Yes that was it my php.ini file had "mail.log = " uncommented by
default. Once I removed that line the warning disappeared.
Thank you for your help. Sorry for the bogus report.
Regards
Jeffrey
[2009-03-02 15:30:45] ka...@php.net
Have you enabled the mailing logging feature thats available as of PHP
5.3 and not defined a mail log setting (mail.log)
[2009-03-02 12:50:31] jeffreybolle at gmail dot com
Description:
When using the mail() function PHP displays an irrelevant warning
message.
Reproduce code:
---
mail("jeffreybo...@gmail.com","test subject","test message");
Expected result:
The email is sent and no warnings are displayed.
Actual result:
--
The email is sent but the following warning is displayed:
Warning: mail() [function.mail]: Filename cannot be empty in {script
name} on line {line number}
--
Edit this bug report at http://bugs.php.net/?id=47543&edit=1
#43866 [Bgs]: Can't define the connect timeout on mysqli extension class
ID: 43866
Updated by: dani...@php.net
Reported By: basilio dot vera at softonic dot com
Status: Bogus
Bug Type: MySQLi related
Operating System: Linux RHEL4
PHP Version: 5.2.5
New Comment:
Examples added to manual.
Previous Comments:
[2008-01-17 18:35:52] u...@php.net
Not a bug, solution is given, documentation "flaw" discussed.
[2008-01-17 17:54:44] basilio dot vera at softonic dot com
For example with an example inside the mysqli_init() or
mysqli_options() function docs:
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::init();
parent::options( MYSQLI_OPT_CONNECT_TIMEOUT, 5 );
parent::real_connect( $host, $user, $pass, $db );
}
}
Regards.
[2008-01-17 17:29:50] u...@php.net
Give me a hint, what's up with the documentation?
http://us2.php.net/mysqli_connect shows that calling constructor of the
mysqli class is equal to calling mysqli_connect(). As you know, you need
to call mysqli_options() before a connection has been established. In
your reproduceable code you suggest a derived class which explicitly
calls the parent constructor to create a connection. Once the parent
constructor has been called you try to call mysqli_options()
(mysqli::options()). That's too late.
Your second example gets it right. How could we improve the
documentation? Thanks!
Ulf
[2008-01-17 00:19:51] basilio dot vera at softonic dot com
Hi, I've found a solution for this problem. It can be solved with:
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
$this->init();
$this->options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$this->real_connect( $host, $user, $pass, $db );
}
}
But you may consider review your docs, because it's and undocumented
feature!
[2008-01-16 14:34:39] basilio dot vera at softonic dot com
Sorry, the error message was:
'Couldn't fetch mysqli2'
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/43866
--
Edit this bug report at http://bugs.php.net/?id=43866&edit=1
#45940 [Csd]: MySQLI OO does not populate connect_error property on failed connect
ID: 45940 Updated by: dani...@php.net Reported By: talmage dot news at gmail dot com Status: Closed Bug Type: MySQLi related Operating System: Centos 5 PHP Version: 5.2.6 Assigned To: mysql New Comment: Added information to the documentation. Previous Comments: [2009-02-17 10:41:59] johan...@php.net Fixed in 5.2 CVS, too, now. [2009-01-12 12:56:23] johan...@php.net 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. [2009-01-10 10:23:30] nullhility at gmail dot com Getting the same error with the following version: PHP 5.2.4-2ubuntu5.4 with Suhosin-Patch 0.9.6.2 I was attempting to suppress errors so I could control output/formatting etc. Thought i'd just re-iterate this for version related purposes. connect_error); var_dump(mysqli_connect_error()); ?> output: Warning: main(): Couldn't fetch mysqli in /home/default/php/mysqli.php on line 4 NULL string(63) "Access denied for user 'r00t'@'localhost' (using password: YES)" [2008-12-25 21:17:22] ws at develtheory dot com Was able to reproduce the error in the same method on php 5.2.8, both with purposeful incorrect passwords and nonexistent host/port combos. the object is created, connect_error returns NULL on var_dump, error log dumps: "Dec 25 15:12:18 dev01 httpd: PHP Warning: dbo::__construct() [dbo.--construct]: Couldn't fetch mysqli in /nfs/beta/www/classes/dbo-new.inc.php on line 88" [2008-12-01 13:39:16] dannyrjohnston at msn dot com Forget my previous comment. I found some code between the new mysqli statement in the example I was using which was setting the $dbObj to false if mysql_connect_error was returning a value. 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/45940 -- Edit this bug report at http://bugs.php.net/?id=45940&edit=1
Bug #43817 [Fbk->Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817&edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible -Status: Feedback +Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: I just installed 5.3.2. The regression has gotten worse. Now the "Subdir/.." workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... Previous Comments: [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 [2010-03-29 00:12:25] dani...@php.net Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. [2009-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-06-20 11:39:09] paj...@php.net Can't reproduce it with RC4, please try again with 5.3.0RC4. [2009-03-02 20:09:55] paj...@php.net Also see #42832 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817&edit=1
Bug #43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817&edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: That makes sense. I'm on XP. Thanks. If you need quicker feedback, shoot me an email or assign the bug to me. Previous Comments: [2010-04-05 01:59:43] paj...@php.net Nothing has changed in 5.2/3.x about that. The problem may come from the tsrm's real path which tries to access all parent directories to cache them. I have to investigate why it fails on XP (and on on 2003 for your right?) but not on more recent versions. [2010-04-05 01:45:01] dani...@php.net I just installed 5.3.2. The regression has gotten worse. Now the "Subdir/.." workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 [2010-03-29 00:12:25] dani...@php.net Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. [2009-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
-Summary: DateTime::diff calculates diffs incorrectly
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
Previous Comments:
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
Previous Comments:
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?
Previous Comments:
[2010-01-06 01:04:18] dani...@php.net
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Here is an updated patch against PHP_5_3. It removes all of the
"next_month" code in
do_range_limit_days_relative().
http://www.analysisandsolutions.com/php/bug49081v2.53.diff
As with the earlier patch, PHP built fine with it and all of the
ext/date tests that passed under
the unpached PHP_5_3 build continued to pass under the patched
version.
Grepping the entire PHP_5_3 code base indicates the only place
do_range_limit_days_relative() gets
called is in timelib_do_rel_normalize(), and the only place that gets
called is timelib_diff().
It is unclear what purpose the "next_month" functionality served.
Perhaps it was there in case the
"base_y" and "base_m" parameters were later than the "y"/"m"/"d"
parameters? But that doesn't apply
becausetimelib_diff() always passes the earlier date to
timelib_do_rel_normalize() as "one" and on to
do_range_limit_days_relative() as "base_*".
Previous Comments:
[2010-01-06 16:19:14] dani...@php.net
Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?
[2010-01-06 01:04:18] dani...@php.net
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInter
Bug #43817 [NoF->Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817&edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible -Status: No Feedback +Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. Previous Comments: [2009-06-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-06-20 11:39:09] paj...@php.net Can't reproduce it with RC4, please try again with 5.3.0RC4. [2009-03-02 20:09:55] paj...@php.net Also see #42832 [2009-03-02 20:01:18] paj...@php.net I can now reproduce it on XP, but not on 2008/Vista/win7. I have to investigate deeper :P [2009-02-03 17:36:35] dani...@php.net Changing version from 5.2.5 to 5.3.0beta1 to facilitate this getting fixed before the next release. 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817&edit=1
Bug #47627 [Bgs->Dup]: "No input file specified" causing crash
Edit report at http://bugs.php.net/bug.php?id=47627&edit=1 ID: 47627 Updated by: dani...@php.net Reported by: danielc at analysisandsolutions dot com Summary: "No input file specified" causing crash -Status: Bogus +Status: Duplicate Type: Bug Package: CGI related Operating System: win32 only - WinXP Pro SP3 PHP Version: 5.3CVS-2009-03-11 (snap) -Assigned To: garretts +Assigned To: Previous Comments: [2009-10-19 17:04:45] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289757 Log: - Merge: improve fix for #49767 and #47627 - make PHP report 'no script' on 404 again [2009-10-16 23:34:32] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=289706 Log: improve fix for #49767 and #47627 - make PHP report "no script" on 404 again [2009-10-15 21:32:24] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=289687 Log: - Merge: fix crash for bug #47627 [2009-10-13 19:59:00] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revision&revision=289621 Log: fix crash for bug #47627 [2009-10-13 19:50:36] paj...@php.net That's correct and has been analyzed in #49767, will be fixed there. Please note that the condition is not only that the file does not exist but also to use when the per directory registry setting is used. Set this one as bogus as the one will be used to track this bug. Thanks for having reproduced it Stas :) 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/bug.php?id=47627 -- Edit this bug report at http://bugs.php.net/bug.php?id=47627&edit=1
#36688 [NoF->Bgs]: date() doesnt five right date sometimes
ID: 36688
Updated by: [EMAIL PROTECTED]
Reported By: phil at adigital dot com dot mx
-Status: No Feedback
+Status: Bogus
Bug Type: Date/time related
Operating System: Win XP and Linux FC4
PHP Version: 5.1.2
New Comment:
The United States changed Daylight Savings Time start/end:
<= 2006: 1st Sunday in April at 2:00 am
>= 2007: 2nd Sunday in March at 2:00 am
TEST:
-
OUTPUT:
---
1172989800 = Sun, 04 Mar 2007 01:30:00 -0500
1172993400 = Sun, 04 Mar 2007 02:30:00 -0500
---
1173594600 = Sun, 11 Mar 2007 01:30:00 -0500
1173598200 = Sun, 11 Mar 2007 03:30:00 -0400
---
1174199400 = Sun, 18 Mar 2007 02:30:00 -0400
1174203000 = Sun, 18 Mar 2007 03:30:00 -0400
---
1174804200 = Sun, 25 Mar 2007 02:30:00 -0400
1174807800 = Sun, 25 Mar 2007 03:30:00 -0400
---
1175409000 = Sun, 01 Apr 2007 02:30:00 -0400
1175412600 = Sun, 01 Apr 2007 03:30:00 -0400
---
1176013800 = Sun, 08 Apr 2007 02:30:00 -0400
1176017400 = Sun, 08 Apr 2007 03:30:00 -0400
---
Previous Comments:
[2006-10-30 16:57:34] gxt3 at dowling dot edu
I can confirm the bug of date() shifting one hour. I use
date in a calendar app :
date("d",(mktime(0,0,0,$month,$day,$year)+$m*24*60*60))
where m goes from 0 to 1 and $month, $day, $year are given
by the user. So it is either mktime or date problem.
for the last week of November the timestamps returned are:
27 Nov: 1161921600
28 Nov: 1162008000
29 Nov: 1162094400
30 Nov: 1162180800 (Bug here it is 23:00PM of 29th yet )
31 Nov: 1162267200 (Bug still here )
01 Oct: 1162353600 (Bug still present)
02 Oct: 116244 (Same here)
The following week (my weeks start on Friday) the times are
back to normal.
The system is slackware 10.2 and I have not seen this bug in
the past year. This is the first week that it occurs.
[2006-03-19 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-03-11 16:52:51] [EMAIL PROTECTED]
What timezone did you configure your server to use? (date.timezone
php.ini setting).
[2006-03-10 23:48:22] phil at adigital dot com dot mx
Description:
date("Y-m-d H:i:s", 1175403600);
shows: 2007/4/1 00:00:00
Should be: 2007/3/1 23:00:00
the hour is shift 1 hour in PHP from march/11/2007 to april/1/2007 (20
days of 1 hour diff !)
The same problem repeat 2008, 2009, 2010, 2011, etc, but the beginning
of problem is +/- 5 days and ending problem too +/- 5 days
It seems the problem is not occuring before 3/1/2007
I thought first it was maybe a daylight savings problem
BUT:
- it happens on our redhat 8 servers in US (ev1), local servers (FC4)
AND windows XP
- the start and end date of the problem is quite random in a period ,
daylights are quite fixed
- It doesnt happen before 3/1/2007
SO i guess it's a bad bug somewhere
the result *must* be same as unix_timestamp C++ function no ?
It is not
Thx !
Reproduce code:
---
print date("Y-m-d H:i:s", 1175403600); // bad +1 hour
print date("Y-m-d H:i:s", 1238417200); // bad +1 hour
print mktime(0,0,0,4,1,2007);
Expected result:
2007/3/1 23:00:00
2009-03-30 06:46:40
1175407200
Actual result:
--
2007/4/1 00:00:00
2009-03-30 07:46:40
1175403600
--
Edit this bug report at http://bugs.php.net/?id=36688&edit=1
#38781 [WFx->Bgs]: strtotime() generates wrong date for 11th month 2007 on.
ID: 38781
Updated by: [EMAIL PROTECTED]
Reported By: rpk at npstrategy dot com
-Status: Wont fix
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux Fedora Core 4
PHP Version: 4.4.4
New Comment:
= 2007: Second Sunday in March at 2:00 am
* End:
* <= 2006: Last Sunday in October at 2:00 am
* >= 2007: First Sunday in November at 2:00 am
*
* http://aa.usno.navy.mil/faq/docs/daylight_time.html
*/
// SPRING --
// 2006
//$t1 = strtotime('2006-03-05 02:30:00');
//$t2 = strtotime('2006-03-05 01:30:00');
//
// 2007
//$t1 = strtotime('2007-03-04 01:30:00');
//$t2 = strtotime('2007-03-04 02:30:00');
// --
// FALL
// 2006
//$t1 = strtotime('2006-10-22 01:30:00');
//$t2 = strtotime('2006-10-22 02:30:00');
//
// 2007
$t1 = strtotime('2007-10-21 01:30:00');
$t2 = strtotime('2007-10-21 02:30:00');
// --
$step = 60 * 60 * 24 * 7; // Increment one week
for ($i = 0; $i < 6; $i++) {
echo $t1 . ' = ' . date('r', $t1) . "\n";
echo $t2 . ' = ' . date('r', $t2) . "\n";
echo "---\n";
$t1 = $t1 + $step;
$t2 = $t2 + $step;
}
OUTPUT:
---
1192944600 = Sun, 21 Oct 2007 01:30:00 -0400
1192948200 = Sun, 21 Oct 2007 02:30:00 -0400
---
1193549400 = Sun, 28 Oct 2007 01:30:00 -0400
1193553000 = Sun, 28 Oct 2007 02:30:00 -0400
---
1194154200 = Sun, 04 Nov 2007 01:30:00 -0400
1194157800 = Sun, 04 Nov 2007 01:30:00 -0500
---
1194759000 = Sun, 11 Nov 2007 00:30:00 -0500
1194762600 = Sun, 11 Nov 2007 01:30:00 -0500
---
1195363800 = Sun, 18 Nov 2007 00:30:00 -0500
1195367400 = Sun, 18 Nov 2007 01:30:00 -0500
---
1195968600 = Sun, 25 Nov 2007 00:30:00 -0500
1195972200 = Sun, 25 Nov 2007 01:30:00 -0500
Previous Comments:
[2006-09-12 08:31:43] [EMAIL PROTECTED]
I still can not reproduce it.
month11_2006_date for Friday 2006 = 17(correct)
month11_2007_date = 16 (wrong)
Anyway, we're not going to do any major changes in PHP4.
The datetime related code was rewritten in 5.1, which you should use
instead.
[2006-09-11 21:28:49] rpk at npstrategy dot com
running program
http://southo.org/date_test.php
Code:
$month11_2006_timestamp = mktime(0,0,0,11,1,2006);
$month11_2006_day_timestamp = strtotime("3
Friday",$month11_2006_timestamp);
$month11_2006_date = date('j',$month11_2006_day_timestamp);
echo"month11_2006_date for Friday 2006 = $month11_2006_date
(correct)";
$month11_2007_timestamp = mktime(0,0,0,11,1,2007);
$month11_2007_day_timestamp = strtotime("3
Friday",$month11_2007_timestamp);
$month11_2007_date = date('j',$month11_2007_day_timestamp);
echo"month11_2007_date = $month11_2007_date (wrong)";
[2006-09-11 18:29:09] [EMAIL PROTECTED]
Can't reproduce with both 4.4 and 5.2.
I get 17 and 16, both are correct results.
Also, please try to be more clear when you provide reproduce code. Lot
of HTML and text do not add any understanding.
[2006-09-11 18:16:17] rpk at npstrategy dot com
Description:
strtotime starts generating wrong timestamps in November, 2007. Only
wrong in the month of November. Rest of months are ok.
strtotime("3 Friday", $november_2006_timestamp) generates correct
timestamp with date which is the 3rd Friday in November 2006.
strtotime("3 Friday", $november_2007_timestamp) generates wrong
timestamp with date which should be the 3rd Friday in November 2007.
The date generated is -1 day, in this case, Thursday in the month of
November, 2007.
All dates generated are wrong in the months of November. Tested up to
2009. Every other month works ok.
Reproduce code:
---
month11_2006_date for Friday 2006 = $month11_2006_date
(correct)";
echo"This correctly shows the 3rd Friday date for November, 2006
";
//test of strtotime() generating date string for day in 3 week in
November 2007
$month11_2007_timestamp = mktime(0,0,0,11,1,2007);
$month11_2007_day_timestamp = strtotime("3
Friday",$month11_2007_timestamp);
$month11_2007_date = date('j',$month11_2007_day_timestamp);
echo"month11_2007_date = $month11_2007_date (wrong)";
echo"This incorrectly shows the 3rd Friday date for November, 2007
as the 15th of November 2007 which is a Thursday.
Every day-date generated from November 2007-2009 produces at -1
day from the standard.
So other days are also wrong. It is always November. The other
months work fine.";
Expected result:
month11_2006_date for Friday 2006 = 17 (correct)
This correctly shows the 3rd Friday date for November, 2006
month11_2007_date = 15 (wrong)
This incorrectly shows the 3rd Friday
Bug #54719 [Opn->Csd]: Serialization tests fail to set serialize_precision
Edit report at http://bugs.php.net/bug.php?id=54719&edit=1 ID: 54719 Updated by: dani...@php.net Reported by:mats dot lindh at gmail dot com Summary:Serialization tests fail to set serialize_precision -Status: Open +Status: Closed Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:trunk-SVN-2011-05-12 (SVN) -Assigned To: +Assigned To:tyrael Block user comment: N Private report: N New Comment: Patch applied by tyrael on 2011-05-16. Previous Comments: [2011-05-12 13:23:06] mats dot lindh at gmail dot com Description: The tests for the serialization module fails to set the INI value for serialize_precision before running the tests, resulting in failed tests if the default precision is used (if the tests are run before make install and no php.ini file is available). Test script: --- make test TESTS=ext/standard/tests/serialize Expected result: Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 50 ( 98.0%) (100.0%) Actual result: -- Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:5 ( 9.8%) ( 10.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 45 ( 88.2%) ( 90.0%) -- Edit this bug report at http://bugs.php.net/bug.php?id=54719&edit=1
Bug #60237 [Asn->Dup]: TLA timezone dates produce wrong results with add/diff
Edit report at https://bugs.php.net/bug.php?id=60237&edit=1
ID: 60237
Updated by: dani...@php.net
Reported by:s...@php.net
Summary:TLA timezone dates produce wrong results with
add/diff
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5.4.0beta2
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=55253.
Previous Comments:
[2011-11-07 18:15:45] s...@php.net
Description:
If you diff two dates with TLA timezone (like EDT) and then add the interval
back
to the earliest date, you would not get the later date but instead the result
will
be one hour off. See example below.
Test script:
---
$start = new DateTime('2010-06-04 02:18:48 EDT');
var_dump($start->format('U'));
$end = new DateTime('2010-06-06 18:38:28 EDT');
$ts = $end->format('U');
var_dump($start, $end);
$int = $start->diff($end);
var_dump($int, $start);
var_dump($start->format('U'));
$res = $start->add($int);
var_dump($res);
Expected result:
.
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-06-06 18:38:28"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}
Actual result:
--
...
object(DateTime)#1 (3) {
["date"]=>
string(19) "2010-06-06 17:38:28"
["timezone_type"]=>
int(2)
["timezone"]=>
string(3) "EDT"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60237&edit=1
Bug #54799 [Asn->Dup]: Incorrect results when operating with time on DST changes
Edit report at https://bugs.php.net/bug.php?id=54799&edit=1
ID: 54799
Updated by: dani...@php.net
Reported by:robertoherreros at gmail dot com
Summary:Incorrect results when operating with time on DST
changes
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.6
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=51051
Previous Comments:
[2011-05-18 08:34:47] robertoherreros at gmail dot com
One more thing:
// BAD
// 2011-03-27, 02:00:00 -> 03:00:00
// Expected: 2011-03-27 03:30:00, Actual: 2011-03-27 02:30:00
// 2011-03-27 02:30:00 don't exists
$tz = new DateTimezone('Europe/Madrid');
$d = new DateTime('2011-03-27 02:30:00',$tz);
echo $d->format('Y-m-d H:i:s').'';
[2011-05-17 16:57:51] robertoherreros at gmail dot com
Description:
Incorrect results when operating with time on DST changes.
Operations like: '-1 hour', '-1 min' or setTime()
In order to resolve the problem, all operations with time must be done in
timestamp directly.
Test script:
---
// 2011-03-27, 02:00:00 -> 03:00:00
$tz = new DateTimezone('Europe/Madrid');
$d = new DateTime('2011-03-28 02:30:00',$tz);
// OK
// One day early
// Result: 2011-03-27 03:30:00
echo $d->modify('-1 day')->format('Y-m-d H:i:s').'';
// BAD
// One hour early (or other TIME operation)
// Expected: 2011-03-27 01:30:00, Actual: 2011-03-27 03:30:00
echo $d->modify('-1 hour')->format('Y-m-d H:i:s').'';
// BAD
// SetDate and setTime
// Expected: 2011-03-27 03:30:00, Actual: 2011-03-27 02:30:00
echo $d->setDate(2011,3,27)->setTime(2,30,0)->format('Y-m-d H:i:s').'';
// OK
// Set timezone again after setDate and setTime fix the above problem
// Result: 2011-03-27 03:30:00
echo $d->setDate(2011,3,27)->setTime(2,30,0)->setTimezone($tz)->format('Y-m-d
H:i:s').'';
// OK
// One hour early but changing timestamp
// Result: 2011-03-27 01:30:00
echo $d->setTimestamp(($d->getTimestamp()-3600))->format('Y-m-d H:i:s').'';
// OK
// One hour after
// Result: 2011-03-27 03:30:00
echo $d->modify('2011-03-27 01:30:00')->modify('+1 hours')->format('Y-m-d
H:i:s').'';
// BAD
// Two hours after
// Expected: 2011-03-27 04:30:00, Actual: 2011-03-27 03:30:00
echo $d->modify('2011-03-27 01:30:00')->modify('+2 hours')->format('Y-m-d
H:i:s').'';
Expected result:
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 04:30:00
Actual result:
--
2011-03-27 03:30:00
2011-03-27 03:30:00
2011-03-27 02:30:00
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 03:30:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=54799&edit=1
Bug #54495 [Opn->Bgs]: Empty DateInterval has wrong days
Edit report at https://bugs.php.net/bug.php?id=54495&edit=1 ID: 54495 Updated by: dani...@php.net Reported by:bandy dot chris at gmail dot com Summary:Empty DateInterval has wrong days -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: Linux, x86_64 PHP Version:5.3.6 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: "days" is a calculated field expressing how many days are between two compared dates. It is never set when instantiating a new date interval. The "d" property contains the number of days specified in the interval format. Everything is operating as expected. Previous Comments: [2011-04-08 17:34:08] bandy dot chris at gmail dot com Description: A DateInterval created with a period that spans zero days reports $days = FALSE rather than 0. A DateInterval created by subtracting two DateTimes reports $days = 0 correctly. Test script: --- 0 [m] => 0 [d] => 0 [h] => 0 [i] => 0 [s] => 0 [invert] => 0 [days] => 0 ) DateInterval Object ( [y] => 0 [m] => 0 [d] => 0 [h] => 0 [i] => 0 [s] => 0 [invert] => 0 [days] => 0 ) Actual result: -- DateInterval Object ( [y] => 0 [m] => 0 [d] => 0 [h] => 0 [i] => 0 [s] => 0 [invert] => 0 [days] => ) DateInterval Object ( [y] => 0 [m] => 0 [d] => 0 [h] => 0 [i] => 0 [s] => 0 [invert] => 0 [days] => 0 ) -- Edit this bug report at https://bugs.php.net/bug.php?id=54495&edit=1
Bug #53880 [Opn->Dup]: date_diff returns wrong results
Edit report at https://bugs.php.net/bug.php?id=53880&edit=1
ID: 53880
Updated by: dani...@php.net
Reported by:an0nym at narod dot ru
Summary:date_diff returns wrong results
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Windows Server 2008 R2 x64
PHP Version:5.3.5
-Assigned To:
+Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
This is a duplicate of http://bugs.php.net/bug.php?id=51184
Previous Comments:
[2011-05-08 11:48:46] eikcam at internode dot on dot net
I'm running Windows 7 64-bit and I am having this issue.
DateInterval Object ( [y] => 0 [m] => 1 [d] => 30 [h] => 0 [i] => 0 [s] => 0
[invert] => 0 [days] => 6015 )
[2011-01-30 15:12:45] an0nym at narod dot ru
Pay attention to the end of description. Windows 7 x64 doesn't have this bug,
while Windows Server 2008 R2 do and they have much more simiral codebase than
Windows XP and Windows Server 2008 R2.
[2011-01-30 15:09:38] an0nym at narod dot ru
I didn't compile myself. I downloaded VC6 x86 thread safe from windows binaries
php download page.
[2011-01-30 10:53:57] s...@php.net
Works fine for me on XP 32-bit with VC9. Which compiler/build did you use?
[2011-01-29 23:42:08] an0nym at narod dot ru
Description:
See test script.
On FreeBSD 8.1-RELEASE-p1 amd64, Linux 2.6.18-194.32.1.el5 x86_64, Windows 7
x64
everything works fine.
Test script:
---
date_default_timezone_set("UTC");
$d = new DateTime("2011-01-01");
echo $d->diff(new DateTime("2010-01-01"))->format("%a");
Expected result:
365
Actual result:
--
6015
--
Edit this bug report at https://bugs.php.net/bug.php?id=53880&edit=1
Bug #53370 [Opn->Dup]: Some relative date/time format returns incorrect result at the end of DST
Edit report at https://bugs.php.net/bug.php?id=53370&edit=1 ID: 53370 Updated by: dani...@php.net Reported by:for-bugs at hnw dot jp Summary:Some relative date/time format returns incorrect result at the end of DST -Status: Open +Status: Duplicate Type: Bug Package:Date/time related Operating System: Linux and MacOSX PHP Version:5.3.3 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: This is a duplicate of https://bugs.php.net/bug.php?id=51051 Previous Comments: [2010-11-21 13:38:57] for-bugs at hnw dot jp Description: Relative date/time format '+[number]sec', '+[number]min', '+[number]hour' returns incorrect time when the current time is in daylight saving time and the result of calculation is non-daylight saving time. For example, daylight saving time of this year in the USA was started at 2010-03-14 02:00:00, and finished at 2010-11-07 02:00:00. However, '2010-11-07 01:59:59 +1sec' advance to 3601 sec after. Test script: --- https://bugs.php.net/bug.php?id=53370&edit=1
Bug #53225 [Opn->Dup]: add-Method of DateTime-class
Edit report at https://bugs.php.net/bug.php?id=53225&edit=1
ID: 53225
Updated by: dani...@php.net
Reported by:i dot sonderegger at meteonews dot ch
Summary:add-Method of DateTime-class
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.5.8
PHP Version:5.3SVN-2010-11-02 (snap)
-Assigned To:
+Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=55253
Previous Comments:
[2010-11-02 08:41:25] i dot sonderegger at meteonews dot ch
Description:
PHP-Version:
PHP 5.3.99-dev (cli) (built: Nov 1 2010 17:42:09)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
If a timezone is passed in the time-string to the constructor of the
DateTime-Object, a subsequent add() call could result in incorrect results (if
the add() call oversteps a daylight-saving time).
Test script:
---
// Gives expected result
$date = new DateTime('2010-10-31 01:00 CEST', new
DateTimeZone("Europe/Zurich"));
$date->setTimezone(new DateTimeZone('Europe/Zurich'));
$date->add(new DateInterval('PT3H'));
echo $date->format('Y-m-d H:i:sP')."\n";
// Doesn't give expected result
$date = new DateTime('2010-10-31 01:00 CEST', new
DateTimeZone("Europe/Zurich"));
$date->add(new DateInterval('PT3H'));
$date->setTimezone(new DateTimeZone('Europe/Zurich'));
echo $date->format('Y-m-d H:i:sP')."\n";
Expected result:
2010-10-31 04:00:00+01:00
2010-10-31 04:00:00+01:00
Actual result:
--
2010-10-31 04:00:00+01:00
2010-10-31 03:00:00+01:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=53225&edit=1
Req #54117 [Opn->Wfx]: Parameter 'z' false
Edit report at https://bugs.php.net/bug.php?id=54117&edit=1
ID: 54117
Updated by: dani...@php.net
Reported by:a dot borngesser at berlin dot de
Summary:Parameter 'z' false
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Date/time related
Operating System: Irrelevant
PHP Version:Irrelevant
-Assigned To:
+Assigned To: danielc
Block user comment: N
Private report: N
New Comment:
It is impossible to change the behavior of an existing format parameter due to
the current behavior being relied on by existing users. If you like, you may
open a feature request for a new format parameter, but this does not seem like
an important feature since using z + 1 is a simple workaround.
Previous Comments:
[2011-03-16 09:42:49] a dot borngesser at berlin dot de
Is someone working on this issue or shut I open a new thread (and of course in
english this time)?
[2011-02-28 11:29:03] a dot borngesser at berlin dot de
Sorry, my text now in english.
The parameter 'z' is false from its basic set-up.
The first day of the year is '1' not '0'.
I know, that the count starts with 0, but it would be better to change the code
of the parameter, than to leave it to the programmers.
(I had some cases where it was used simply as is. The results where simply
false, and when using it in a very basic way by just displaying it, you don't
think of a mistake.)
If a parameter is for returning the "incremented day of the year", it should do
exactly this, and not the "incremented day of the year -1".
[2011-02-28 11:11:34] paj...@php.net
Please report your bug in English.
[2011-02-28 11:10:18] a dot borngesser at berlin dot de
Description:
---
>From manual page: http://www.php.net/function.date#Parameter-Liste
---
Parameter ist im Grundaufbau falsch.
"z Der Tag des Jahres (von 0 beginnend)0 bis365"
=== =
Der erste Tag des Jahres ist nicht '0' sondern '1'!
Natürlich ist es normal, das von 0 die Zählung beginnt, aber man sollte evtl.
bei einem Parameter dies intern gleich um +1 hochzählen und nicht den
Programmierern überlassen.
Ich habe jetzt schon mehrere Fälle gehabt, wo der Parameter direkt genutzt
wurde, was dann zu falschen Ergebnissen geführt hat.
Wenn ein Parameter den hochgezählten Tag des Jahres angeben soll, sollte dies
auch so sein und nicht 'der hochgezählte Tag des Jahres -1'.
Test script:
---
echo "Der 1.1. 2010 hatte die LOS#: ".date ("z",mktime(0,0,0,1,1,2010));
Expected result:
Der 1.1. 2010 hatte die LOS#: 1
Actual result:
--
Der 1.1. 2010 hatte die LOS#: 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=54117&edit=1
Bug #55792 [Opn->Bgs]: strtotime("-1 month");
Edit report at https://bugs.php.net/bug.php?id=55792&edit=1
ID: 55792
Updated by: dani...@php.net
Reported by:fjm20016 at 163 dot com
Summary:strtotime("-1 month");
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: windows
PHP Version:5.3.8
-Assigned To:
+Assigned To: danielc
Block user comment: N
Private report: N
New Comment:
1) Use the add(), sub() or modify() DateTime methods for date math.
2) Adding months to dates on or after the 29th of the month is unreliable, as
you've found. When performing such operations, an advisable approach is
changing the date to the first day of the month, add or subtract the number of
months desired, than change the date to the last day of that month.
Previous Comments:
[2011-09-27 02:13:46] fjm20016 at 163 dot com
Description:
I often use strtotime, I won't change my program anywhere.
+1 month -1 month maybe as expected
Test script:
---
date("Y-m-d H:i:s", strtotime("-1 month", strtotime("2011-05-31 00:00:00")));
//2011-05-01 as expected
//2011-04-30 I Like
date("Y-m-d H:i:s", strtotime("+1 month", strtotime("2011-05-31 00:00:00")));
//2011-07-01 as expected
//2011-06-30 I Like
date("Y-m-d H:i:s", strtotime("-1 month", strtotime("2011-03-31 00:00:00")));
//2011-03-03 as expected
//2011-02-28 I Like
--
Edit this bug report at https://bugs.php.net/bug.php?id=55792&edit=1
Bug #63073 [Opn]: master "make install" fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073&edit=1 ID: 63073 Updated by: dani...@php.net Reported by:php at bof dot de Summary:master "make install" fails to install PEAR Status: Open Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit -PHP Version:master-Git-2012-09-12 (Git) +PHP Version:5.5 Block user comment: N Private report: N New Comment: This needs to be fixed so PHP 5.5 can be properly tested. Things work as expected when building PHP <= 5.4. Previous Comments: [2012-10-14 11:06:27] bobvin at pillars dot net Branch master does not compile and also is missing file sapi/fpm/php- fpm.service.in Running git-bisect to find the break point, This is the commit that broke compilation: commit 4968fa644b0849321e1761e52b8db15dd46f9b75 Author: theanomaly...@gmail.com Date: Tue Apr 17 07:31:36 2012 -0400 Fixed bug #61038; "Z" and better behavior for unpack() Added new "Z" argument to pack/unpack, now allowing "a" to return data without stripping, and "A" strips all trailing white space, while "Z" will strip everything after the first null. [2012-09-12 15:30:17] php at bof dot de Description: I'm building PHP master from current git (at 5246d6f02e52798e343bd5208692f1a5ed89b9d9) Compile works fine, but on "make install", PEAR does not install. See "Actual result" regarding the error output I get. I can successfully compile AND install, with identical configure, the PHP-5.4.6 release, so I don't think that there is anything wrong with my build environment. I tried to copy over pecl, pear, and the pear environment, from the 5.4 build/install. pecl and pear search works. download or install fetches the file, but then fails with a similar "could not extract" error. Test script: --- make install Expected result: Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar- already installed: 1.3.7 [PEAR] Console_Getopt - already installed: 1.3.0 [PEAR] Structures_Graph- already installed: 1.0.4 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.9.4 Actual result: -- Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar: could not extract the package.xml file from "phar://install- pear-nozlib.phar/Archive_Tar-1.3.7.tar" [PEAR] Console_Getopt: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar" [PEAR] Structures_Graph: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar" [PEAR] XML_Util: could not extract the package.xml file from "phar://install- pear-nozlib.phar/XML_Util-1.2.1.tar" [PEAR] PEAR: could not extract the package.xml file from "phar://install-pear- nozlib.phar/PEAR-1.9.4.tar" -- Edit this bug report at https://bugs.php.net/bug.php?id=63073&edit=1
#26418 [NEW]: loading class files crashes
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-26 (dev) PHP Bug Type: Reproducible crash Bug description: loading class files crashes Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via "new." I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit bug report at http://bugs.php.net/?id=26418&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26418&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26418&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26418&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26418&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26418&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26418&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26418&r=support Expected behavior: http://bugs.php.net/fix.php?id=26418&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26418&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26418&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26418&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26418&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26418&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26418&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26418&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26418&r=float
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -n -i | grep argv register_argc_argv => On => On _SERVER["argv"] => Array C:\PROGRA~1\php\cli>php -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) Previous Comments: [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r " var_dump($_SERVER['argv']); " 1 2 3 -------- [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php now execute test script... ./t.php fjiao Expected result: Array ( [0] => ./t.php [1] => fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -r " var_dump($_SERVER['argv']); " 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL Previous Comments: [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. ---- [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -n -i | grep argv register_argc_argv => On => On _SERVER["argv"] => Array C:\PROGRA~1\php\cli>php -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r " var_dump($_SERVER['argv']); " 1 2 3 -------- [2003-11-11 12:52:32] danielc at analysisandsolutions dot com Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php now execute test script... ./t.php fjiao Expected result: Array ( [0] => ./t.php [1] => fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26418 [Fbk->Opn]: loading class files crashes
ID: 26418 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Windows 2000 PHP Version: 5CVS-2003-11-26 (dev) New Comment: Same problem with new snapshot: php5-win32-200312010330.zip Previous Comments: [2003-11-28 23:48:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-11-26 02:24:47] danielc at analysisandsolutions dot com Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via "new." I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit this bug report at http://bugs.php.net/?id=26418&edit=1
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which "C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries. The PHP DLL's have never been copied to any other location on this computer. Previous Comments: [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) ---- [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -r " var_dump($_SERVER['argv']); " 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. -------- [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -n -i | grep argv register_argc_argv => On => On _SERVER["argv"] => Array C:\PROGRA~1\php\cli>php -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r " var_dump($_SERVER['argv']); " 1 2 3 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26418 [Fbk->Opn]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
#! c:/progra~1/php/cli/php
http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is <= 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?>
Previous Comments:
[2003-12-01 03:22:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
--------
[2003-12-01 00:39:30] danielc at analysisandsolutions dot com
Same problem with new snapshot: php5-win32-200312010330.zip
[2003-11-28 23:48:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
--------
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via "new."
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418&edit=1
#26206 [Bgs->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. Previous Comments: [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which "C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) ---- [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cli>php -i | grep argv register_argc_argv => On => On C:\PROGRA~1\php\cli>php -r " var_dump($_SERVER['argv']); " 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. Previous Comments: [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which "C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26418 [Fbk->Csd]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
Works fine so far. Thanks.
Previous Comments:
[2003-12-15 09:48:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Can not reproduce..
[2003-12-01 13:41:57] danielc at analysisandsolutions dot com
#! c:/progra~1/php/cli/php
http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is <= 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?>
--------
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via "new."
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418&edit=1
#26791 [NEW]: mssql.textlimit and mssql.textsize can't be set via ini_set()
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: mssql.textlimit and mssql.textsize can't be set via ini_set()
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit bug report at http://bugs.php.net/?id=26791&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26791&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26791&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26791&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26791&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26791&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26791&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26791&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26791&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26791&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26791&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26791&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26791&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26791&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26791&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26791&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26791&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26791&r=float
#20797 [Com]: 4k text limitation can be adjusted by INI_SET
ID: 20797
Comment by: danielc at analysisandsolutions dot com
Reported By: carl dot landry at emergis dot com
Status: No Feedback
Bug Type: MSSQL related
Operating System: Windows NT 4.0 build 1381
PHP Version: 4.2.2
New Comment:
This is still an issue. Opened new bug:
http://bugs.php.net/bug.php?id=26791
Previous Comments:
[2003-01-02 18:41:35] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-12-07 01:20:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-03 13:05:28] carl dot landry at emergis dot com
To adjust the 4k limitation of TEXT fields, I changed the TEXTSIZE and
TEXTLIMIT value of MSSQL (SET TEXTSIZE xxx) to a very high value to
prevent interference. This works properly.
Adjusting the "mssql.textlimit" and "mssql.textsize" values in php.ini
would allow larger than 4k results to be returned. This seems also
fine.
However, changing this limit at run time ("ini_set("mssql.textlimit",
12000); ini_set("mssql.textsize", 12000);", 12000 (int) or "12000"
string, not making a difference) would have no impact on the selected
result.
PHPINFO() shows the new adjusted value but the result would still be
limited to the value set in the PHP.INI file.
Also, "-1" (as suggested in the INI_SET function description page)
seems to limit to 4k too.
Server API: ISAPI
MSSQL Library version: 7.0
More information can be supplied if requested.
--
Edit this bug report at http://bugs.php.net/?id=20797&edit=1
#26799 [NEW]: divide by zero errors not reported
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: divide by zero errors not reported
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1> SELECT 0/0 AS FOO
2> go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
["foo"]=>
NULL
}
--
Edit bug report at http://bugs.php.net/?id=26799&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26799&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26799&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26799&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26799&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26799&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26799&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26799&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26799&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26799&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26799&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26799&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26799&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26799&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26799&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26799&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26799&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26799&r=float
#26799 [Bgs->Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
Previous Comments:
[2004-01-05 16:45:24] [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
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1> SELECT 0/0 AS FOO
2> go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
["foo"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799&edit=1
#26799 [Fbk->Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter < 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo '';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
Previous Comments:
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [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
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1> SELECT 0/0 AS FOO
2> go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
["foo"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799&edit=1
#26799 [Opn->Csd]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Closed
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Close it.
Previous Comments:
[2004-01-06 23:27:16] danielc at analysisandsolutions dot com
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter < 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo '';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [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
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1> SELECT 0/0 AS FOO
2> go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
["foo"]=>
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799&edit=1
#26206 [NoF->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Sorry I didn't reply sooner. Situation still exists as of 500rc1-dev--php5-win32-200401022330. I still working on getting the build environment to function properly so I can determine when the change happened. Previous Comments: [2004-01-06 20:53:16] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2004-01-01 21:08:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-12-02 00:31:23] danielc at analysisandsolutions dot com Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26206 [Fbk->Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No dice using php5-win32-200401081130 Previous Comments: [2004-01-07 21:38:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try the latest snapshot. [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which "C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26791 [Opn]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Know what? The problem was where the ini_set() calls are made. They
must be done BEFORE the connection is established. Once it's made, it
can't be changed.
Oddly, it doesn't matter when one calls ini_set() for
mssql.datetimeconvert.
So, I'm not sure this bug report should be closed, called bogus or not.
It might be nice to have these work regardless of where they are
called. If no change is made, the behavior needs to be documented.
Couple things to keep in mind about my config:
Using CGI
Loading mssql via php.ini extensions
Versions 4.3.4 and php5-win32-200401081130 snapshot
Previous Comments:
[2004-01-08 00:12:28] [EMAIL PROTECTED]
This seams to be related to how the extension is loaded.
ini_set() works fine in php4 whn the extension is loaded from php.ini,
but not when dl() is used.
The dl() will also cause the output from phpinfo() to be incomplete!
[2004-01-06 18:56:04] [EMAIL PROTECTED]
Frank, nothing has changed in that function. Are you sure this really
works with PHP 5..?
[2004-01-05 02:44:12] [EMAIL PROTECTED]
This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did
something happen to the ini_set() funtion ?
[2004-01-05 01:34:58] danielc at analysisandsolutions dot com
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no
feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit this bug report at http://bugs.php.net/?id=26791&edit=1
#26791 [Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Sniper: Don't be so dismissive. Most ini_set()'s work just fine regardless of when they're called. Sessions aren't a good example because all of the session stuff has to be processed before any output. If the team doesn't want to spend time fixing this, please turn this into a documentation bug for ref.mssql.php, where a note should be made about the need to set these before connecting to a db. Previous Comments: [2004-01-08 23:21:09] [EMAIL PROTECTED] Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) ---- [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? 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/26791 -- Edit this bug report at http://bugs.php.net/?id=26791&edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
INVOCATION:
C:\PROGRA~1\php>php argvtest.php 1 2
OUTPUT:
array(3) {
[0]=>
string(12) "argvtest.php"
[1]=>
string(1) "1"
[2]=>
string(1) "2"
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
Previous Comments:
----
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
----
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
--------
[2003-12-01 12:04:35] danielc at analysisandsolutions dot com
100% certain.
New PHP installs on this system are by moving the entirety of the old
install aside, extracting the contents of a new snapshot .zip file then
copying the exact files/structure over to the php directory. The
system finds the DLLS via the %path%, in which
"C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls;" are the first two entries.
The PHP DLL's have never been copied to any other location on this
computer.
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/26206
--
Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Here's a link to the discussion on the interals list back in October
about these changes:
http://marc.theaimsgroup.com/?t=10650930736&r=1&w=2
This is a link to the current discussion regarding the situation and
how either I'm misunderstanding things or things may not be working as
expected:
http://marc.theaimsgroup.com/?t=10743658311&r=1&w=2
Previous Comments:
----
[2004-01-17 14:17:35] danielc at analysisandsolutions dot com
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
INVOCATION:
C:\PROGRA~1\php>php argvtest.php 1 2
OUTPUT:
array(3) {
[0]=>
string(12) "argvtest.php"
[1]=>
string(1) "1"
[2]=>
string(1) "2"
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
--------
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
--------
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
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/26206
--
Edit this bug report at http://bugs.php.net/?id=26206&edit=1
#25724 [Com]: register_long_arrays breaks superglobals
ID: 25724 Comment by: danielc at analysisandsolutions dot com Reported By: kauer at face-online dot de Status: Verified Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2004-01-03 New Comment: Bug 26206 -- http://bugs.php.net/bug.php?id=26206 -- has been marked as a duplicate of this one. Previous Comments: [2004-01-21 02:05:14] [EMAIL PROTECTED] And both register_globals and register_long_arrays have to be off to reproduce this! [2004-01-21 02:03:44] [EMAIL PROTECTED] Only these superglobals are broken: $_SERVER $_ENV $_REQUEST All other work fine.. [2003-11-28 21:20:42] [EMAIL PROTECTED] Reproducable with this quick'n'dirty way too: # sapi/cli/php -d'register_long_arrays=off' -r 'var_dump($_SERVER);' [2003-10-02 04:55:56] kauer at face-online dot de Description: Using the binary from snaps.php.net, turning register_long_arrays off in .htaccess will make $_SERVER unavailable. Reproduce code: --- File: .htaccess php_flag register_long_arrays off PHP: var_dump($_SERVER); Expected result: I expect to see a variable dump of $_SERVER. Actual result: -- var_dump outputs NULL -- Edit this bug report at http://bugs.php.net/?id=25724&edit=1
#27123 [NEW]: casting arrays to objects and back
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000 and OS X 10.3
PHP version: 5CVS-2004-02-03 (dev)
PHP Bug Type: Reproducible crash
Bug description: casting arrays to objects and back
Description:
Found PEAR DB's getAssoc() method didn't work correctly when in
DB_FETCHMODE_OBJECT mode. See pear/DB/tests/18get.phpt for that.
I pared it down a bit and then Adam Trachtenberg whittled it down even
farther. Here's what he found:
1) Use an array with a string key: array('a' => 1)
2) Cast it to an object and call get_object_vars()
on the result.
3) Assign this cast object to an array with
multiple elements.
4) Call print_r() on the resulting array.
If I remove any of these, the crash goes away.
Reproduce code:
---
1);
get_object_vars($element);
$array[] = $element;
print_r($array);
?>
Expected result:
Array
(
[0] => 1
[1] => stdClass Object
(
[a] => 1
)
)
Actual result:
--
~ WINDOWS 2000 ~
Array
(
[0] => 1
[1] => stdClass Object
(
[a] => 1130656883
)
)
~ OS X 10.3, PHP = beta 3 ~
No Output.
~ OS X 10.3, PHP = recent CVS ~
Array
(
[0] => 1
[2] => stdClass Object
(
[a] =>
... backtrace ...
#0 0x00271308 in _zend_is_inconsistent (ht=0x5a5a5a5a, file=0x3183f8
"/usr/local/cvs/php/php-src/Zend/zend_hash.c", line=504) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:53
#1 0x00273384 in zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:504
#2 0x002658a8 in _zval_dtor (zvalue=0xbfffe710, __zend_filename=0x3178bc
"/usr/local/cvs/php/php-src/Zend/zend_operators.c", __zend_lineno=510) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:52
#3 0x0025d240 in _convert_to_string (op=0xbfffe710,
__zend_filename=0x317b5c "/usr/local/cvs/php/php-src/Zend/zend.c",
__zend_lineno=256) at
/usr/local/cvs/php/php-src/Zend/zend_operators.c:510
#4 0x0026691c in zend_make_printable_zval (expr=0xace8d0,
expr_copy=0xbfffe710, use_copy=0xbfffe720) at
/usr/local/cvs/php/php-src/Zend/zend.c:256
#5 0x002669dc in zend_print_zval_ex (write_func=0x208fa0
, expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:275
#6 0x00266984 in zend_print_zval (expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:266
#7 0x00265d24 in zend_print_variable (var=0xace8d0) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:171
#8 0x00267094 in zend_print_zval_r_ex (write_func=0x208fa0
, expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:387
#9 0x00266dc8 in zend_print_zval_r (expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#10 0x002662c8 in print_hash (ht=0xace860, indent=12, is_object=1 '\001')
at /usr/local/cvs/php/php-src/Zend/zend.c:159
#11 0x00267074 in zend_print_zval_r_ex (write_func=0x208fa0
, expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:381
#12 0x00266dc8 in zend_print_zval_r (expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#13 0x002662c8 in print_hash (ht=0xacde60, indent=4, is_object=0 '\0') at
/usr/local/cvs/php/php-src/Zend/zend.c:159
#14 0x00266ed4 in zend_print_zval_r_ex (write_func=0x208fa0
, expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:356
#15 0x00266dc8 in zend_print_zval_r (expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#16 0x00165a10 in zif_print_r (ht=1, return_value=0xacea98, this_ptr=0x0,
return_value_used=0) at
/usr/local/cvs/php/php-src/ext/standard/basic_functions.c:2570
#17 0x0029d5ac in zend_do_fcall_common_helper (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2550
#18 0x0029dff4 in zend_do_fcall_handler (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2697
#19 0x00297a20 in execute (op_array=0xacdda8) at
/usr/local/cvs/php/php-src/Zend/zend_execute.c:1264
#20 0x002689bc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/cvs/php/php-src/Zend/zend.c:1051
#21 0x00209bf8 in php_execute_script (primary_file=0xb720) at
/usr/local/cvs/php/php-src/main/main.c:1641
#22 0x002aac60 in main (argc=2, argv=0xbc94) at
/usr/local/cvs/php/php-src/sapi/cli/php_cli.c:939
--
Edit bug report at http://bugs.php.net/?id=27123&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27123&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27123&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27123&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27123&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27123&r=nee
#27368 [NEW]: php.ini-(dist|recommended) have CR at end
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-02-23 (dev) PHP Bug Type: *Configuration Issues Bug description: php.ini-(dist|recommended) have CR at end Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit bug report at http://bugs.php.net/?id=27368&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27368&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27368&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27368&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27368&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27368&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27368&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27368&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27368&r=support Expected behavior: http://bugs.php.net/fix.php?id=27368&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27368&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27368&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27368&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27368&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27368&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27368&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27368&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27368&r=float
#27368 [Bgs->Opn]: php.ini-(dist|recommended) have CR at end
ID: 27368 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5CVS-2004-02-23 (dev) New Comment: Where were you looking? In CVS or in the files distributed in a php5-win32-200402231530 snapshot? They are definitely there in the snapshot. I can email you the files if you don't believe me. This may be due to the new build system, which when it went into effect threw in loads of CR's even though the raw files in CVS were fine. I posted a note to internals and it seems someone fixed something to make all but one of the CR's disappeared. Previous Comments: [2004-02-23 13:17:01] [EMAIL PROTECTED] In CVS: ; tab-width: 4 ; End: (there is no CR there) [2004-02-23 12:23:31] danielc at analysisandsolutions dot com Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit this bug report at http://bugs.php.net/?id=27368&edit=1
#25987 [Com]: php and xml tag confusion
ID: 25987 Comment by: danielc at analysisandsolutions dot com Reported By: tkwright_233 at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: * New Comment: This needlessly causes problems for users. It would be nice to fix it, please. tkwright_233 seems on target when they say: PHP knows "the diffrence of '' to '?>'), from v.2 to v.4 . [2003-10-26 15:24:32] [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 It does recognize the difference, if you disable short_tags, which you should for exactly this reason. [2003-10-25 15:18:05] [EMAIL PROTECTED] Short tags = ''."\n";?> Reproduce code: --- Expected result: [no error],rest of page Actual result: -- Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=25987&edit=1
#31979 [Bgs->Opn]: msql_fetch_field() not reporting unique keys
ID: 31979
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-15
New Comment:
Jani, you can do better than that. Are you saying you ran my test and
got the expected result? Or are you passing the buck?
Previous Comments:
[2005-06-07 00:24:32] [EMAIL PROTECTED]
Apparently the msql version you've compiled PHP does not set the field
properly.
[2005-02-15 05:26:25] danielc at analysisandsolutions dot com
Description:
One of the properties returned by msql_fetch_field() is "unique". It
is supposed to contain 1 if the column in question is part of a unique
key and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] => i
[table] => blah
[not_null] => 0
[unique] => 1
[type] => int
)
Actual result:
--
stdClass Object
(
[name] => i
[table] => blah
[not_null] => 0
[unique] => 0
[type] => int
)
--
Edit this bug report at http://bugs.php.net/?id=31979&edit=1
#25826 [NEW]: undefined notices via unset()
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: Irrelevant PHP Bug Type: Zend Engine 2 problem Bug description: undefined notices via unset() Description: unset() acts inconsistently when acting upon array keys that don't exist. In some cases it throws Notices about "Undefined index" "Undefined variable" and "Undefined property." The behavior varies depending on a) the dimension of the array trying to be unset b) whether the array is set c) if the unset() call is in a class d) the version of PHP being used Reproduce code: --- Nada); // no problem unset($this->Array1['one:one']);// 4.3.3: Undefined property // 500b2: no problem unset($this->Array1['one:two'][1]); // 4.3.3: Undefined property // 500b2: no problem unset($this->Array2['two:one']);// no problem unset($this->Array2['two:two'][1]); // Undefined index unset($Nada); // no problem unset($Array3['three:one']);// Undefined variable unset($Array3['three:two'][1]); // Undefined variable $Array4 = array(); unset($Array4['four:one']); // no problem unset($Array4['four:two'][1]); // Undefined index } } $test1 = new test(); unset($Nada); // no problem unset($Array5['five:one']); // Undefined variable unset($Array5['five:two'][1]); // Undefined variable $Array6 = array(); unset($Array6['six:one']); // no problem unset($Array6['six:two'][1]); // Undefined index ?> Expected result: No notices at all. Considering no notice was produced on a non-existant scalar, I expected the same behavior when trying to unset various arrays, regardless of where the unset() all is made. Actual result: -- PHP 4.3.3 Notice: Undefined property: Array1 in t.php on line 12 Notice: Undefined property: Array1 in t.php on line 13 Notice: Undefined index: two:two in t.php on line 16 Notice: Undefined variable: Array3 in t.php on line 20 Notice: Undefined variable: Array3 in t.php on line 21 Notice: Undefined index: four:two in t.php on line 25 Notice: Undefined variable: Array5 in t.php on line 33 Notice: Undefined variable: Array5 in t.php on line 34 Notice: Undefined index: six:two in t.php on line 38 PHP 500b2-dev 200310010230 Notice: Undefined index: two:two in t.php on line 16 Notice: Undefined variable: Array3 in t.php on line 20 Notice: Undefined variable: Array3 in t.php on line 21 Notice: Undefined index: four:two in t.php on line 25 Notice: Undefined variable: Array5 in t.php on line 33 Notice: Undefined variable: Array5 in t.php on line 34 Notice: Undefined index: six:two in t.php on line 38 -- Edit bug report at http://bugs.php.net/?id=25826&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25826&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25826&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25826&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25826&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25826&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25826&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25826&r=support Expected behavior: http://bugs.php.net/fix.php?id=25826&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25826&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25826&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25826&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25826&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25826&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25826&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25826&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25826&r=float
#26090 [NEW]: allow colons in time zone offset to strtotime()
From: danielc at analysisandsolutions dot com
Operating system: n/a
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Feature/Change Request
Bug description: allow colons in time zone offset to strtotime()
Description:
The strtotime() function doesn't allow time zone offsets to contain colons
":" in them. Colons are included in several offset formmating standards.
Reproduce code:
---
$t = '2003-10-28 10:20:30-0800';
echo date('Y-m-d H:i:s T', strtotime($t)) . "\n\n";
$t = '2003-10-28 10:20:30-08:00';
echo date('Y-m-d H:i:s T', strtotime($t)) . "\n";
Expected result:
2003-10-28 13:20:30 EST
2003-10-28 13:20:30 EST
Actual result:
--
2003-10-28 13:20:30 EST
1969-12-31 18:59:59 EST
On Windows 2000, the attempt with the colons in the offset produces a
negative timestamp, so the beloved "Windows does not support dates prior
to midnight" warning arises.
--
Edit bug report at http://bugs.php.net/?id=26090&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26090&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26090&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26090&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26090&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26090&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26090&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26090&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26090&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26090&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26090&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26090&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26090&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26090&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26090&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26090&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26090&r=float
#23467 [Com]: Showing incorrect Time Zone
ID: 23467
Comment by: danielc at analysisandsolutions dot com
Reported By: John at JGSystems dot net
Status: Verified
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.4-dev, 5.0.0b2-dev
New Comment:
Um, sorry if I'm cluttering the list... This bug is half a year old so
I'm wondering if/when it's going to get fixed.
Y'all probably know what's going on, but allow me to clarify what I've
learned about this bug, perhaps it will help someone.
date('T') doesn't work under Windows during Daylight times and there's
no notation of this in the manual. I'll put a user comment in there.
Here's a test script:
";
putenv('TZ=EST5EDT');
echo 'EST5EDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=PST8PDT');
echo 'PST8PDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=GMT0BST');
echo 'GMT0BST: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=MST-3MDT');
echo 'MST-3MDT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
echo "\n";
putenv('TZ=GMT');
echo 'GMT: dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
?>
OUTPUT DURING EASTERN DAYLIGHT TIME
---
Local: dT=BST dO=-0400 sZ=Eastern Daylight Time
EST5EDT: dT=BST dO=-0400 sZ=EDT
PST8PDT: dT=BST dO=-0700 sZ=PDT
GMT0BST: dT=BST dO=+0100 sZ=BST
MST-3MDT: dT=BST dO=+0400 sZ=MDT
GMT: dT=GMT dO=+ sZ=GMT
OUTPUT DURING EASTERN STANDARD TIME
---
Local: dT=Eastern Standard Time dO=-0500 sZ=Eastern Standard Time
EST5EDT: dT=EST dO=-0500 sZ=EST
PST8PDT: dT=PST dO=-0800 sZ=PST
GMT0BST: dT=GMT dO=+ sZ=GMT
MST-3MDT: dT=MST dO=+0300 sZ=MST
GMT: dT=GMT dO=+ sZ=GMT
Previous Comments:
[2003-08-26 22:59:32] [EMAIL PROTECTED]
This is general win32 problem. No need to post anymore comments here,
we know about it.
[2003-08-20 20:35:39] John at JGSystems dot net
Here ya go:
Commands:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
echo date("T"),"\n";
Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST
This what you wanted? (I hope)
[2003-08-19 23:12:26] John at JGSystems dot net
The time last modified was pasted in the reply.
This page was last modified:
Monday - May 19, 2003 at 4:22 PM BST.
I'll get the current time pasted in tomorrow...
The results of:
echo date("r"),"\n";
echo date("I"),"\n"; // uppercase "i"
Too late tonight...
[2003-08-19 22:48:30] [EMAIL PROTECTED]
I wanted to know the TIME...not the time zone..
[2003-08-19 21:12:06] John at JGSystems dot net
It's a local machine. Win XP. Nothings changed from the items listed
below in this thread or I would have mentioned it.
I downloaded the link, installed it after erasing the last version you
all had me try and the same result. I did tell you that it was
supposed to be --> MDT <-- not --> BST <--
Thanks...
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/23467
--
Edit this bug report at http://bugs.php.net/?id=23467&edit=1
#26206 [NEW]: argv and argc not defined
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2003-11-11 (dev) PHP Bug Type: Unknown/Other Function Bug description: argv and argc not defined Description: $_SERVER['argv'] and $_SERVER['argc'] aren't created. php.ini and phpinfo() show register_argc_argv as being On. Behavior is the same via CLI or CGI binaries. Substituted a known good php.ini file to see ensure the file was getting parsed. Same results. Everything worked fine under 500b2-dev--php5-win32-200310010230 Problem began when upgraded to 500b2-dev--php5-win32-200311040330 Persists in the current CVS snapshot 500b3-dev--php5-win32-20031530 Reproduce code: --- #! c:/progra~1/php/cli/php now execute test script... ./t.php fjiao Expected result: Array ( [0] => ./t.php [1] => fjiao ) Actual result: -- Notice: Undefined index: argv in d:\t.php on line 3 -- Edit bug report at http://bugs.php.net/?id=26206&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26206&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26206&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26206&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26206&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26206&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26206&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26206&r=support Expected behavior: http://bugs.php.net/fix.php?id=26206&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26206&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26206&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26206&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26206&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26206&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26206&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26206&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26206&r=float
#26207 [NEW]: date(): add format parameter for colons in UTC offset
From: danielc at analysisandsolutions dot com
Operating system: irrelevant
PHP version: Irrelevant
PHP Bug Type: Feature/Change Request
Bug description: date(): add format parameter for colons in UTC offset
Description:
date('O') produces the offset in "+0200" format. It would be nice to be
able to have a format parameter that
outputs the same information but with a colon in it: "+02:00."
--
Edit bug report at http://bugs.php.net/?id=26207&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26207&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26207&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26207&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26207&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26207&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26207&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26207&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26207&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26207&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26207&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26207&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26207&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26207&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26207&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26207&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26207&r=float
#28229 [NEW]: PATCH run-tests tripped up by spaces in names
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2004-04-30 (dev) PHP Bug Type: Unknown/Other Function Bug description: PATCH run-tests tripped up by spaces in names Description: While running tests on my Windows machine I ran into a problem with run-tests.php. .phpt files which have spaces in their names/paths cause the tests to fail. The .out file contains text along the lines of Could not open C:\Programs As you can guess, the .phpt files were in a subdirectory of c:\program files\. The following patch places quotes around the file names when creating the $cmd: http://www.analysisandsolutions.com/php/run-tests.spaceinfilename.diff -- Edit bug report at http://bugs.php.net/?id=28229&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28229&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28229&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28229&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28229&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28229&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28229&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28229&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28229&r=support Expected behavior: http://bugs.php.net/fix.php?id=28229&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28229&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28229&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28229&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28229&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28229&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28229&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28229&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28229&r=float
#28478 [NEW]: won't build: "'convert_scalar_to_number' : too few actual parameters"
From: danielc at analysisandsolutions dot com Operating system: win PHP version: 4CVS-2004-05-21 (stable) PHP Bug Type: Sybase-ct (ctlib) related Bug description: won't build: "'convert_scalar_to_number' : too few actual parameters" Description: I downloaded the latest PHP 4 windows snapshot and found php_sybase_ct.dll isn't in the extensions directory. The compile log shows... Compiling... php_sybase_ct.c c:\php4build\snap\ext\sybase_ct\php_sybase_ct.c(1136) : error C2198: 'convert_scalar_to_number' : too few actual parameters (from http://snaps.php.net/win32/compile-STABLE.log) -- Edit bug report at http://bugs.php.net/?id=28478&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28478&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28478&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28478&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28478&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28478&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28478&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28478&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28478&r=support Expected behavior: http://bugs.php.net/fix.php?id=28478&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28478&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28478&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28478&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28478&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28478&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28478&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28478&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28478&r=float
#28354 [Com]: sybase_free_result crash
ID: 28354 Comment by: danielc at analysisandsolutions dot com Reported By: alahaye at fmlogistic dot com Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: Linux RadHat 7 PHP Version: 4.3.6 New Comment: I'm experienceing this on Windows builds as well. The problem arose some time between these two snapshots: works php4-win32-STABLE-200401210130 crashes php4-win32-STABLE-200402161330 Previous Comments: [2004-05-19 13:55:05] alahaye at fmlogistic dot com Here the backtrace (gdb) bt #0 0x40ba7df0 in chunk_free (ar_ptr=0x40c50f00, p=0x8436518) at malloc.c:3131 #1 0x40ba7d59 in __libc_free (mem=0x84368e8) at malloc.c:3054 #2 0x0816ed49 in shutdown_memory_manager (silent=0, clean_cache=0) at /users/sources/php/php-4.3.6/Zend/zend_alloc.c:492 #3 0x08154c44 in php_request_shutdown (dummy=0x0) at /users/sources/php/php-4.3.6/main/main.c:1003 #4 0x0819870d in main (argc=2, argv=0xb70c) at /users/sources/php/php-4.3.6/sapi/cli/php_cli.c:873 #5 0x40b44177 in __libc_start_main (main=0x8197bd4 , argc=2, ubp_av=0xb70c, init=0x8086330 <_init>, fini=0x82500c0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xb6fc) at ../sysdeps/generic/libc-start.c:129 [2004-05-18 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-05-11 14:01:18] sergio dot zia at saipm dot com I am encountering exactly the same problem :-( Linux RedHat AS 2.1 PHP 4.3.6 [2004-05-10 22:55:49] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-05-10 22:28:19] alahaye at fmlogistic dot com Description: When using sybase_free_result, apache Segmentation fault. PB doesn't exist with PHP 4.3.4. Reproduce code: --- "; } sybase_free_result($result); sybase_close($id); ?> Expected result: result of stored procedure -- Edit this bug report at http://bugs.php.net/?id=28354&edit=1
#30184 [NEW]: run-tests error_reporting / ~E_STRICT ignored in phpt files
From: danielc at analysisandsolutions dot com Operating system: Win 2000 PHP version: 5CVS-2004-09-21 (dev) PHP Bug Type: Unknown/Other Function Bug description: run-tests error_reporting / ~E_STRICT ignored in phpt files Description: Using: * PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26) * run-tests.php version 1.195.2.1 or HEAD When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings still come up for code in the .phpt file. The notice isn't generated for code in included files. Reproduce code: --- NOTE: two files... === s.phpt = --TEST-- error_reporting ignored for code in phpt --SKIPIF-- --FILE-- --EXPECT-- === s.inc = http://bugs.php.net/?id=30184&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30184&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30184&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30184&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30184&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30184&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30184&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30184&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30184&r=support Expected behavior: http://bugs.php.net/fix.php?id=30184&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30184&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30184&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30184&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30184&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30184&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30184&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30184&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30184&r=mysqlcfg
#30184 [Opn]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Unknown/Other Function Operating System: Win 2000 PHP Version: 5CVS-2004-09-21 (dev) New Comment: Something else to take into consideration is run-tests.php is overriding the error_reporting settings from php.ini. This is causing tests to fail even though the same tests worked fine under development versions of PHP 5. Here's a new set of test scripts... === s.phpt --TEST-- error_reporting ignored for code in phpt --SKIPIF-- --FILE-- --EXPECT-- Default error_reporting in s.phpt: 2047 The error_reporting in s.inc: 2047 Subsequent error_reporting in s.phpt: 2047 === s.inc --EXPECT-- === s.inc = http://bugs.php.net/?id=30184&edit=1
#30184 [Bgs]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Win 2000 PHP Version: 5CVS-2004-09-21 (dev) New Comment: Andi: Thanks for the --INI-- tip. Regarding your first email which said "make sure that E_STRICT is turned off in the INI," php.ini already had reporting set to E_ALL but it's being ignored. The reason I posted it as a bug was this issue seems to have only arose in the recent past. This issue hadn't come up while I was developing DB and HTML_Form even though I've been running snapshots of PHP 5 for a long while. Thanks again. Previous Comments: [2004-09-22 23:43:23] [EMAIL PROTECTED] And you should use an --INI-- section in your test file for this anyway. [2004-09-22 23:04:31] [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 Certain E_STRICT notices (such as var being deprecated) are emited at compile-time therefore changing the error_reporting (which only happens at run-time) will not affect it. You will need to make sure that E_STRICT is turned off in the INI. One work around for the tests might be to put the source in an include file and change error_reporting before we include it. This issue was discussed on internals@ a few months back and this behavior was agreed on because some of these E_STRICT issues have to be detected at compile-time. ---- [2004-09-21 23:34:25] danielc at analysisandsolutions dot com Something else to take into consideration is run-tests.php is overriding the error_reporting settings from php.ini. This is causing tests to fail even though the same tests worked fine under development versions of PHP 5. Here's a new set of test scripts... === s.phpt --TEST-- error_reporting ignored for code in phpt --SKIPIF-- --FILE-- --EXPECT-- Default error_reporting in s.phpt: 2047 The error_reporting in s.inc: 2047 Subsequent error_reporting in s.phpt: 2047 === s.inc --EXPECT-- === s.inc = http://bugs.php.net/?id=30184&edit=1
#29733 [Com]: printf handles repeated placeholders wrong
ID: 29733
Comment by: danielc at analysisandsolutions dot com
Reported By: bugs dot php dot net at bluetwanger dot de
Status: Open
Bug Type:Strings related
PHP Version: 5.0.1
New Comment:
Note, the error only happens when mixing numbered and non-numberd
directives. Tweaking the example from the original bug report to use
only numbered directives eliminates the error:
printf('%1$s - %2$s %3$s %3$s %2$s', 1, 2, 3);
Previous Comments:
[2004-08-27 14:36:16] bugs dot php dot net at bluetwanger dot de
Here's a link:
http://www.bluetwanger.de/~mbertheau/formatted_print.c.patch
You make it really hard to submit a patch. This bug thing has no
provision for attaching a file and you have to strain a lot to get at
an email address of a developer mailing list.
[2004-08-27 14:30:33] bugs dot php dot net at bluetwanger dot de
Here's a patch:
--- ext/standard/formatted_print.c.orig 2004-07-18 19:28:04.0
+0200
+++ ext/standard/formatted_print.c 2004-08-27 14:23:07.580732341
+0200
@@ -537,12 +537,6 @@
php_sprintf_appendchar(&result, &outpos, &size,
'%' TSRMLS_CC);
inpos += 2;
} else {
- if (currarg >= argc && format[inpos + 1] !=
'%') {
- efree(result);
- efree(args);
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, "Too few arguments");
- return NULL;
- }
/* starting a new format specifier, reset
variables */
alignment = ALIGN_RIGHT;
adjusting = 0;
@@ -574,13 +568,6 @@
argnum += format_offset;
- if (argnum >= argc) {
- efree(result);
- efree(args);
- php_error_docref(NULL
TSRMLS_CC, E_WARNING, "Too few arguments");
- return NULL;
- }
-
/* after argnum comes modifiers */
PRINTF_DEBUG(("sprintf: looking for
modifiers\n"
"sprintf: now
looking at '%c', inpos=%d\n",
@@ -635,6 +622,13 @@
argnum = currarg++ + format_offset;
}
+if (argnum >= argc) {
+efree(result);
+efree(args);
+php_error_docref(NULL TSRMLS_CC, E_WARNING, "Too few
arguments");
+return NULL;
+}
+
if (format[inpos] == 'l') {
inpos++;
}
Let's see if the line breaks survive.
It basically removes the bogus (format[inpos + 1] != '%' will always be
true there) arg number check and moves the right one outside the special
case for "complicated" format specifiers.
[2004-08-18 14:46:41] bugs dot php dot net at bluetwanger dot de
Description:
printf('%s - %s %s %3$s %2$s', 1, 2, 3);
complains:
Warning: printf(): Too few arguments in /home/bertheau/printf.php on
line 2
printf('%s - %s %s %3$s %2$s', 1, 2, 3, 4);
does not complain and prints:
1 - 2 3 3 2
I expect the first version to not complain and print what the second
version prints.
--
Edit this bug report at http://bugs.php.net/?id=29733&edit=1
#31960 [NEW]: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-13 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_row() and msql_fetch_array() dropping columns with
NULL values
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that contain
NULL values. It's important to retrieve all data from a row, even if it's
NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to watch
out for items that have NULL/0/'' values, it doesn't exactly say what the
problem is and it only talks about results that have only one column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query("INSERT INTO blah VALUES (1, 'a')", $con);
msql_query("INSERT INTO blah VALUES (2, NULL)", $con);
msql_query("INSERT INTO blah VALUES (NULL, 'c')", $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo "\n";
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(2) {
["i"]=>
string(1) "2"
["c"]=>
NULL
}
array(2) {
["a"]=>
NULL
["c"]=>
string(1) "c"
}
Actual result:
--
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(1) {
["i"]=>
string(1) "2"
}
array(1) {
["c"]=>
string(1) "c"
}
--
Edit bug report at http://bugs.php.net/?id=31960&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31960&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31960&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31960&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31960&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31960&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31960&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31960&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31960&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31960&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31960&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31960&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31960&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31960&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31960&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31960&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31960&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31960&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31960&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31960&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31960&r=mysqlcfg
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
-Summary: msql_fetch_row() and msql_fetch_array() dropping
columns with NULL values
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
Previous Comments:
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query("INSERT INTO blah VALUES (1, 'a')", $con);
msql_query("INSERT INTO blah VALUES (2, NULL)", $con);
msql_query("INSERT INTO blah VALUES (NULL, 'c')", $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo "\n";
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(2) {
["i"]=>
string(1) "2"
["c"]=>
NULL
}
array(2) {
["a"]=>
NULL
["c"]=>
string(1) "c"
}
Actual result:
--
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(1) {
["i"]=>
string(1) "2"
}
array(1) {
["c"]=>
string(1) "c"
}
--
Edit this bug report at http://bugs.php.net/?id=31960&edit=1
#31979 [NEW]: msql_fetch_field() not reporting unique keys
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-15 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_field() not reporting unique keys
Description:
One of the properties returned by msql_fetch_field() is "unique". It is
supposed to contain 1 if the column in question is part of a unique key
and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] => i
[table] => blah
[not_null] => 0
[unique] => 1
[type] => int
)
Actual result:
--
stdClass Object
(
[name] => i
[table] => blah
[not_null] => 0
[unique] => 0
[type] => int
)
--
Edit bug report at http://bugs.php.net/?id=31979&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31979&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31979&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31979&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31979&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31979&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31979&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31979&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31979&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31979&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31979&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31979&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31979&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31979&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31979&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31979&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31979&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31979&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31979&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31979&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31979&r=mysqlcfg
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I also put together a patch for the PHP_4_3 branch:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.4_3.diff
It hasn't been tested, but looking at the source of the MySQL extension
makes me think it should work.
Though the script I put in the "Reproduce code" section above doesn't
test what happens with empty strings, I subsequently tested the
behavior and everything works fine.
Previous Comments:
[2005-02-15 02:36:44] danielc at analysisandsolutions dot com
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
----
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query("INSERT INTO blah VALUES (1, 'a')", $con);
msql_query("INSERT INTO blah VALUES (2, NULL)", $con);
msql_query("INSERT INTO blah VALUES (NULL, 'c')", $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo "\n";
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(2) {
["i"]=>
string(1) "2"
["c"]=>
NULL
}
array(2) {
["a"]=>
NULL
["c"]=>
string(1) "c"
}
Actual result:
--
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(1) {
["i"]=>
string(1) "2"
}
array(1) {
["c"]=>
string(1) "c"
}
--
Edit this bug report at http://bugs.php.net/?id=31960&edit=1
#24960 [NEW]: php_domxml.dll in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5.0.0b1 (beta1) PHP Bug Type: *Configuration Issues Bug description: php_domxml.dll in php.ini but not in extensions dir Description: php_domxml.dll is in the php.ini file but is not in the extensions directory. Please either remove the reference to it from php.ini or add the DLL to the extensions directory. -- Edit bug report at http://bugs.php.net/?id=24960&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24960&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24960&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24960&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24960&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24960&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24960&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24960&r=support Expected behavior: http://bugs.php.net/fix.php?id=24960&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24960&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24960&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24960&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24960&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24960&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24960&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24960&r=gnused
#24969 [NEW]: multiple DLLs listed in php.ini but not in extensions dir
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2003-08-07 (dev) PHP Bug Type: *Configuration Issues Bug description: multiple DLLs listed in php.ini but not in extensions dir Description: In the php5-win32-200308070230.zip snapshot... The php.ini file has several DLLs listed in the Windows Extensions section even though the DLLs in question don't exist in the extensions directory: php_curl.dll php_filepro.dll php_hyperwave.dll php_iisfunc.dll php_java.dll php_ldap.dll php_mbstring.dll php_mssql.dll php_oci8.dll php_openssl.dll php_oracle.dll php_pgsql.dll php_printer.dll php_sockets.dll php_w32api.dll php_xmlrpc.dll php_yaz.dll php_zip.dll -- Edit bug report at http://bugs.php.net/?id=24969&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24969&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24969&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24969&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24969&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24969&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24969&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24969&r=support Expected behavior: http://bugs.php.net/fix.php?id=24969&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24969&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24969&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24969&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24969&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24969&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24969&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24969&r=gnused
#28732 [NEW]: temp and tmp environment vars not registered via web
From: danielc at analysisandsolutions dot com Operating system: windows 2000 PHP version: 4.3.7 PHP Bug Type: *General Issues Bug description: temp and tmp environment vars not registered via web Description: Neither the TEMP or TMP environment variables show up via $_ENV, $_SERVER, getenv() or phpinfo() when accessing scripts via a webserver (Apache 1.3.28). They're available when executing scripts via the command line (both CGI and CLI). FYI: C:\PROGRA~1>echo %temp% C:\TEMP C:\PROGRA~1>echo %tmp% C:\TEMP Reproduce code: --- Expected result: TEMP: C:\TEMP temp: C:\TEMP TMP: C:\TEMP tmp: C:\TEMP Actual result: -- === Via web server === TEMP: temp: TMP: tmp: === Via command line === TEMP: C:\TEMP temp: C:\TEMP TMP: C:\TEMP tmp: C:\TEMP -- Edit bug report at http://bugs.php.net/?id=28732&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28732&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28732&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28732&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28732&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28732&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28732&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28732&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28732&r=support Expected behavior: http://bugs.php.net/fix.php?id=28732&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28732&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28732&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28732&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28732&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28732&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28732&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28732&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28732&r=float
#28732 [Opn]: temp and tmp environment vars not registered via web
ID: 28732 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: *General Issues Operating System: windows 2000 PHP Version: 4.3.7 New Comment: Just to be 100% clear, PHP executes via CGI on the web server. Previous Comments: [2004-06-10 20:16:21] danielc at analysisandsolutions dot com Description: Neither the TEMP or TMP environment variables show up via $_ENV, $_SERVER, getenv() or phpinfo() when accessing scripts via a webserver (Apache 1.3.28). They're available when executing scripts via the command line (both CGI and CLI). FYI: C:\PROGRA~1>echo %temp% C:\TEMP C:\PROGRA~1>echo %tmp% C:\TEMP Reproduce code: --- Expected result: TEMP: C:\TEMP temp: C:\TEMP TMP: C:\TEMP tmp: C:\TEMP Actual result: -- === Via web server === TEMP: temp: TMP: tmp: === Via command line === TEMP: C:\TEMP temp: C:\TEMP TMP: C:\TEMP tmp: C:\TEMP -- Edit this bug report at http://bugs.php.net/?id=28732&edit=1
#28912 [NEW]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-06-24 (dev) PHP Bug Type: MySQL related Bug description: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column Description: The "type" value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db->connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db->connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo "type found = $tmp->type\n"; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . "\n"; mysqli_query($db->connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit bug report at http://bugs.php.net/?id=28912&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28912&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28912&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28912&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28912&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28912&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28912&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28912&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28912&r=support Expected behavior: http://bugs.php.net/fix.php?id=28912&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28912&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28912&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28912&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28912&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28912&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28912&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28912&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28912&r=float
#28925 [NEW]: MYSQLI_UNIQUE_KEY_FLAG not found on UNIQUE indexes
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 5CVS-2004-06-25 (dev)
PHP Bug Type: MySQL related
Bug description: MYSQLI_UNIQUE_KEY_FLAG not found on UNIQUE indexes
Description:
MYSQLI_UNIQUE_KEY_FLAG aren't being indicated for columns that have UNIQUE
indexes.
Reproduce code:
---
mysqli_query($db->connection,
'CREATE TABLE phptest_fk (a VARCHAR(5),' .
' UNIQUE (a))');
$r = mysqli_query($db->connection,
'SELECT a FROM phptest_fk');
$tmp = mysqli_fetch_field($r);
echo 'MYSQLI_UNIQUE_KEY_FLAG? ';
if ($tmp->flags & MYSQLI_UNIQUE_KEY_FLAG) {
echo "yes\n";
} else {
echo "no\n";
}
mysqli_query($db->connection,
'DROP TABLE phptest_fk');
Expected result:
MYSQLI_UNIQUE_KEY_FLAG? yes
Actual result:
--
MYSQLI_UNIQUE_KEY_FLAG? no
--
Edit bug report at http://bugs.php.net/?id=28925&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28925&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28925&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28925&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28925&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28925&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28925&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28925&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28925&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28925&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28925&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28925&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28925&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28925&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28925&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28925&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28925&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28925&r=float
#28912 [Fbk->Opn]: 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: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: 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) Previous Comments: [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? ---- [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The "type" value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db->connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db->connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo "type found = $tmp->type\n"; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . "\n"; mysqli_query($db->connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912&edit=1
#28912 [Bgs->Opn]: 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: Bogus +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: 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? 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 ^^^ Previous Comments: [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? [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The "type" value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db->connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db->connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo "type found = $tmp->type\n"; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . "\n"; mysqli_query($db->connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912&edit=1
#28999 [NEW]: exec()'s output array overwritten
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-07-03 (dev) PHP Bug Type: Unknown/Other Function Bug description: exec()'s output array overwritten Description: In PHP 4, when using exec() multiple times with the same array in the "output" parameter, the data from subsequent exec() calls appended the new results to the existing array. This is as the manual says. When PHP 5 first came out, each call to exec() overwrote the prior array. At some point a while ago, there was discussion on the list and things were changed back to the old behavior. At some point after that, the arrays started getting overwritten again. Is this intentional? I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the man page. Can the old behavior be reimplemented in order to preserve compatibility? I made a post about this to internals: http://marc.theaimsgroup.com/?l=php-dev&m=108874256229775&w=2 Reproduce code: --- Expected result: Array ( [0] => The current date is: Fri 07/02/2004 [1] => Enter the new date: (mm-dd-yy) [2] => The current date is: Fri 07/02/2004 [3] => Enter the new date: (mm-dd-yy) ) Actual result: -- Array ( [0] => The current date is: Fri 07/02/2004 [1] => Enter the new date: (mm-dd-yy) ) -- Edit bug report at http://bugs.php.net/?id=28999&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28999&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28999&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28999&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28999&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28999&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28999&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28999&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28999&r=support Expected behavior: http://bugs.php.net/fix.php?id=28999&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28999&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28999&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28999&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28999&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28999&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28999&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28999&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28999&r=float
#28999 [Opn]: exec()'s output array overwritten
ID: 28999 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 5CVS-2004-07-03 (dev) New Comment: Curt Zirzow posted a patch for this to internals... http://news.php.net/php.internals/10968 Previous Comments: [2004-07-03 06:05:05] danielc at analysisandsolutions dot com Description: In PHP 4, when using exec() multiple times with the same array in the "output" parameter, the data from subsequent exec() calls appended the new results to the existing array. This is as the manual says. When PHP 5 first came out, each call to exec() overwrote the prior array. At some point a while ago, there was discussion on the list and things were changed back to the old behavior. At some point after that, the arrays started getting overwritten again. Is this intentional? I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the man page. Can the old behavior be reimplemented in order to preserve compatibility? I made a post about this to internals: http://marc.theaimsgroup.com/?l=php-dev&m=108874256229775&w=2 Reproduce code: --- Expected result: Array ( [0] => The current date is: Fri 07/02/2004 [1] => Enter the new date: (mm-dd-yy) [2] => The current date is: Fri 07/02/2004 [3] => Enter the new date: (mm-dd-yy) ) Actual result: -- Array ( [0] => The current date is: Fri 07/02/2004 [1] => Enter the new date: (mm-dd-yy) ) -- Edit this bug report at http://bugs.php.net/?id=28999&edit=1
[PHP-BUG] Bug #60734 [NEW]: POST, SKIPIF and CLEAN fail if phpt path has spaces
From: Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:POST, SKIPIF and CLEAN fail if phpt path has spaces Description: The POST, SKIPIF and CLEAN sections for phpt fail to execute if the path to the test file has spaces in it. Will attach a patch for run-tests.php. -- Edit bug report at https://bugs.php.net/bug.php?id=60734&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60734&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60734&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60734&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60734&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60734&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60734&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60734&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60734&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60734&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60734&r=support Expected behavior: https://bugs.php.net/fix.php?id=60734&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60734&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60734&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60734&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60734&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60734&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60734&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60734&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60734&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60734&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60734&r=mysqlcfg
Bug #60333 [Opn]: fetch_field() length multiplied by 3 in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60333&edit=1
ID: 60333
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:fetch_field() length multiplied by 3 in mysqlnd
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.4SVN-2011-11-19 (SVN)
Block user comment: N
Private report: N
New Comment:
Can this please be fixed before PHP 5.4 goes out the door?
Previous Comments:
[2011-11-21 18:04:38] danielc at analysisandsolutions dot com
That may be the case, but having UTF-8 fields is legit and the answers from
libmysql and mysqlnd should be the same.
[2011-11-21 17:59:23] william dot bailey at cowboysfromhell dot co dot uk
I think this might be down to what encoding the connection is using.
The length in bytes of a mysql utf8 CHAR(2) field is 6.
If you issue a $db->query('SET NAMES latin1'); before the CREATE TABLE then you
should get the results you are expecting.
[2011-11-19 02:38:53] danielc at analysisandsolutions dot com
Description:
Running PHP 5.4 compiled from svn earlier today. The "length" values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd. The
values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db->query("CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL)");
if (!$result) {
echo "OOPS: $db->error\n";
exit(1);
}
$result = $db->query("INSERT INTO phptest_fk VALUES ('One', 'c1')");
$result = $db->query("SELECT * FROM phptest_fk");
$info = $result->fetch_field();
echo "$info->name $info->length\n";
$info = $result->fetch_field();
echo "$info->name $info->length\n";
$info = $result->fetch_field();
echo "$info->name $info->length\n";
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60333&edit=1
#47629 [Fbk->Opn]: mysqli connect timeout causes fatal error
ID: 47629
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-12 (snap)
Assigned To: pajoye
New Comment:
Because:
1) That's how PHP 5.2 does it.
2) That's how the other socket functions do it in 5.2 and 5.3.
3) The timeout is from communication with another entity, not from the
script itself.
Previous Comments:
[2009-06-20 20:12:24] paj...@php.net
but there is no bug here. Why do you want to let the socket timeout
override the main timeout?
[2009-06-20 17:34:32] dani...@php.net
Yes, the execution timeout makes sense some ways. The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.
[2009-06-20 13:19:04] paj...@php.net
With:
max_execution_time: 2
default_socket_timeout: 6
It is the expected behavior to have a fatal error about the maximum
execution time being exceeded. max_execution_time has the highest
importance.
[2009-03-12 04:41:21] danielc at analysisandsolutions dot com
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11
2009 17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . "\n\n";
echo "ONE ---\n";
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
echo "TWO ---\n";
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properl
#47629 [Opn]: mysqli connect timeout causes fatal error
ID: 47629 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: MySQLi related Operating System: Windows XP SP3 PHP Version: 5.3CVS-2009-03-12 (snap) Assigned To: pajoye New Comment: I'll put together tests of the various functions and report back. Previous Comments: [2009-06-21 09:04:11] paj...@php.net "1) That's how PHP 5.2 does it." Not really relevant in this case. "2) That's how the other socket functions do it in 5.2 and 5.3." Then there is a bug here. "3) The timeout is from communication with another entity, not from the script itself." The max_execution_time has the highest priority and should always has it. If it is not the case in one function or another then there is a bug in this function. -------- [2009-06-21 00:48:41] danielc at analysisandsolutions dot com Because: 1) That's how PHP 5.2 does it. 2) That's how the other socket functions do it in 5.2 and 5.3. 3) The timeout is from communication with another entity, not from the script itself. [2009-06-20 20:12:24] paj...@php.net but there is no bug here. Why do you want to let the socket timeout override the main timeout? [2009-06-20 17:34:32] dani...@php.net Yes, the execution timeout makes sense some ways. The problem is the behavior is inconsistent between 5.2 and 5.3 and between other connection functions. [2009-06-20 13:19:04] paj...@php.net With: max_execution_time: 2 default_socket_timeout: 6 It is the expected behavior to have a fatal error about the maximum execution time being exceeded. max_execution_time has the highest importance. 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/47629 -- Edit this bug report at http://bugs.php.net/?id=47629&edit=1
#47320 [NEW]: $php_errormsg out of scope in functions
From: danielc at analysisandsolutions dot com
Operating system:
PHP version: 5.3.0beta1
PHP Bug Type: Scripting Engine problem
Bug description: $php_errormsg out of scope in functions
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer available
inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . "\n";
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . "\n";
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . "\n";
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit bug report at http://bugs.php.net/?id=47320&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47320&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47320&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47320&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47320&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47320&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47320&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47320&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47320&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47320&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47320&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47320&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47320&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47320&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47320&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47320&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47320&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47320&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47320&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47320&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47320&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47320&r=mysqlcfg
#47320 [Fbk->Opn]: $php_errormsg out of scope in functions
ID: 47320
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0beta1
New Comment:
Compared to 5.2.6.
Previous Comments:
[2009-02-05 23:45:07] j...@php.net
Compared to what version?
[2009-02-05 23:12:59] danielc at analysisandsolutions dot com
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer
available inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . "\n";
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . "\n";
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . "\n";
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit this bug report at http://bugs.php.net/?id=47320&edit=1
#47627 [NEW]: "No input file specified" causing crash
From: danielc at analysisandsolutions dot com Operating system: Windows XP Pro SP3 PHP version: 5.3CVS-2009-03-11 (snap) PHP Bug Type: CGI related Bug description: "No input file specified" causing crash Description: In PHP 5.3, pointing my browser to a .php file that does not exist causes php-cgi to crash and Apache to return a 500 error. In PHP 5.2.6, doing so returns output saying "No input file specified." During the crash, Windows displays the "Please tell Microsoft about this problem" dialog box. The title is "CGI / FastCGI". The "To see what data this error report contains" sub dialog box says: Error signature szAppName : php-cgi.exe szAppVer : 5.3.0.0 szModName : php5ts.dll szModVer : 5.3.0.0 offset : 000cea5d The "To view technical information about the error report" sub sub dialog box contains: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\php-cgi.exe.mdmp C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\appcompat.txt My Apache 1.3 error log message shows: [Wed Mar 11 14:59:02 2009] [error] [client 127.0.0.1] Premature end of script headers: c:/program files/php/php-cgi.exe My PHP version is: PHP 5.3.0beta2-dev (cgi-fcgi) (built: Mar 11 2009 17:04:23) -- Edit bug report at http://bugs.php.net/?id=47627&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47627&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47627&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47627&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47627&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47627&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47627&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47627&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47627&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47627&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47627&r=support Expected behavior: http://bugs.php.net/fix.php?id=47627&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47627&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47627&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47627&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47627&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47627&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47627&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47627&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47627&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47627&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47627&r=mysqlcfg
#47629 [NEW]: mysqli connect timeout causes fatal error
From: danielc at analysisandsolutions dot com
Operating system: Windows XP SP3
PHP version: 5.3CVS-2009-03-12 (snap)
PHP Bug Type: MySQLi related
Bug description: mysqli connect timeout causes fatal error
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11 2009
17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . "\n\n";
echo "ONE ---\n";
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
echo "TWO ---\n";
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n\n";
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit bug report at http://bugs.php.net/?id=47629&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47629&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47629&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47629&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47629&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47629&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47629&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47629&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47629&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47629&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47629&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47629&r=not
#50680 [NEW]: "eight" -> "eighth"
From: danielc at analysisandsolutions dot com Operating system: PHP version: 5.3SVN-2010-01-06 (SVN) PHP Bug Type: Date/time related Bug description: "eight" -> "eighth" Description: In ext/date/lib/parse_date.re, reltextnumber and timelib_reltext_lookup contain ordinal numbers, but when it comes to 8th, it mistakenly uses "eight", rather than "eighth". Guess it now needs to contain both to provide backwards compatibility. -- Edit bug report at http://bugs.php.net/?id=50680&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50680&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50680&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50680&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50680&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50680&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50680&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50680&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50680&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50680&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50680&r=support Expected behavior: http://bugs.php.net/fix.php?id=50680&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50680&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50680&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50680&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50680&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50680&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50680&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50680&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50680&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50680&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50680&r=mysqlcfg
[PHP-BUG] Bug #53463 [NEW]: sqlite3 columnName() segfaults on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnName() segfaults on bad column_number
Description:
PHP's SQLite3Result::columnName() method produces a segmentation fault when
column_number exceeds the column count.
Inside ext/sqlite3/sqlite3.c, PHP utlizes RETVAL_STRING for the data coming
back from SQLite's sqlite3_column_name() function. But inside
ext/sqlite3/libsqlite/sqlite3.c, their sqlite3_column_name() function calls
columnName(), which returns 0 on error conditions.
PHP's C code needs to be adjusted to account for mixed type results from
sqlite3_column_name(). When making this fix, it seems PHP should return
FALSE if sqlite3_column_name() produces 0.
Test script:
---
$db = new SQLite3(':memory:');
$db->exec('CREATE TABLE test (whatever INTEGER)');
$db->exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db->query('SELECT * FROM test');
while ($row = $result->fetchArray(SQLITE3_NUM)) {
var_dump($result->columnName(0)); // string(8) "whatever"
// Seems returning false will be most appropriate.
var_dump($result->columnName(3)); // Segmentation fault
}
$result->finalize();
$db->close();
echo "Done\n";
Expected result:
string(8) "whatever"
bool(false)
Done
Actual result:
--
string(8) "whatever"
Segmentation fault
--
Edit bug report at http://bugs.php.net/bug.php?id=53463&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53463&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53463&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53463&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53463&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53463&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53463&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53463&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53463&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53463&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53463&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53463&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53463&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53463&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53463&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53463&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53463&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53463&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53463&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53463&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53463&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53463&r=mysqlcfg
[PHP-BUG] Bug #53464 [NEW]: sqlite3 columnType() returns SQLITE3_NULL on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnType() returns SQLITE3_NULL on bad column_number
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) when
column_number exceeds the column count. It seems more appropriate for it
to return FALSE.
Test script:
---
$db = new SQLite3(':memory:');
$db->exec('CREATE TABLE test (whatever INTEGER)');
$db->exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db->query('SELECT * FROM test');
while ($row = $result->fetchArray(SQLITE3_NUM)) {
var_dump($result->columnType(0)); // int(1) [SQLITE3_INTEGER]
// Seems returning false is more appropriate.
var_dump($result->columnType(3)); // int(5) [SQLITE3_NULL]
}
$result->finalize();
$db->close();
echo "Done\n";
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit bug report at http://bugs.php.net/bug.php?id=53464&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53464&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53464&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53464&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53464&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53464&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53464&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53464&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53464&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53464&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53464&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53464&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53464&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53464&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53464&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53464&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53464&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53464&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53464&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53464&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53464&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53464&r=mysqlcfg
