#37097 [NEW]: PDO-MSSQL converts bigint to float.
From: stochnagara at hotmail dot com
Operating system: windows xp
PHP version: 5.1.3RC2
PHP Bug Type: PDO related
Bug description: PDO-MSSQL converts bigint to float.
Description:
PDO MsSql driver returns bigint values as float instead of int.
They are always formated as .0
Reproduce code:
---
CREATE TABLE demo (
bi bigint not null,
sm int null
);
insert into demo (1,1);
$result = $pdo->query ("SELECT * FROM demo")->fetch();
echo "bi={$result['bi']};"
echo "sm={$result['sm']};"
Expected result:
bi=1;sm=1;
Actual result:
--
bi=1.0;sm=1;
--
Edit bug report at http://bugs.php.net/?id=37097&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37097&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37097&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37097&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37097&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37097&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37097&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37097&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37097&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37097&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37097&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37097&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37097&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37097&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37097&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37097&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37097&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37097&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37097&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37097&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37097&r=mysqlcfg
#37097 [Opn->Asn]: PDO-MSSQL converts bigint to float.
ID: 37097
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5.1.3RC2
-Assigned To:
+Assigned To: wez
New Comment:
Assigned to the maintainer.
Previous Comments:
[2006-04-16 07:44:32] stochnagara at hotmail dot com
Description:
PDO MsSql driver returns bigint values as float instead of int.
They are always formated as .0
Reproduce code:
---
CREATE TABLE demo (
bi bigint not null,
sm int null
);
insert into demo (1,1);
$result = $pdo->query ("SELECT * FROM demo")->fetch();
echo "bi={$result['bi']};"
echo "sm={$result['sm']};"
Expected result:
bi=1;sm=1;
Actual result:
--
bi=1.0;sm=1;
--
Edit this bug report at http://bugs.php.net/?id=37097&edit=1
#37095 [Opn->Fbk]: cookie returns random value
ID: 37095
Updated by: [EMAIL PROTECTED]
Reported By: giaym at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Windows 2000
PHP Version: 5.1.2
New Comment:
So, your browser sends wrong data to PHP script, am I correct? Why do
you report it to PHP bug system then?
Previous Comments:
[2006-04-16 02:18:33] giaym at hotmail dot com
Oh, same behavior for IE6. The server is located on the same machine as
the browser.
[2006-04-16 02:14:59] giaym at hotmail dot com
Description:
Randomly, the cookies send back random values to the server, values
different than those set the previous page load.
I use session auto start on php.ini. PHP runs on Apache 2.
Reproduce code:
---
a, b, locka and lockb are cookies set with setcookie(, ,
0, "/");
if($somevar == "lock") {
echo "lock";
Set cookies locka and lockb with the values of cookies a and b
respectively.
} else if($somevar == "random") {
echo "random";
Delete locka and lockb, and give a random value to a.
} else {
echo "none";
if(locka not set) Set random value to a.
}
if (b not set) Set random value to b.
Enter pages in that order:
www.domain.com/page/
www.domain.com/page/lock/
www.domain.com/page/random/
www.domain.com/page/lock/
(The if logic works, this is not a case of $somevar holding an
incorrect value.)
Expected result:
www.domain.com/page/
received cookies: none
output: none
sent cookies: a with value x; b with value y
www.domain.com/page/lock/
received cookies: a with value x
output: lock
sent cookies: lock a = x; lock b = y
www.domain.com/page/random/
received cookies: a with value x; b with value y; locka with value x;
lockb with value y
output: random
sent cookies: delete lock a; delete lock b; a = z
www.domain.com/page/lock/
received cookies: a with value z; b with value y
output: lock
sent cookies: lock a = z; lock b = y
Actual result:
--
Everything as expected except the last page load: The cookie received
isn't a = z, it is a = q, I mean, another value. The server then sends
"lock a = q" following the logic.
PHPSESSID is received and reset on every page load.
1.
HTTP Request Headers
HTTP RequestGET /page/ HTTP/1.1
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2)
Gecko/20060308 Firefox/1.5.0.2
HTTP Response Headers
Set-Cookie PHPSESSID=3fo392aek7m274550d9oppqdo6; path=/
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma no-cache
Set-Cookie a=3; path=/
Set-Cookie b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
2. (The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the values of a and b)
HTTP Response Headers
Set-Cookie locka=3; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
3.(The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/random/ HTTP/1.1
Cookie
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52;
locka=3;
lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We delete the locked values and set a random value for a, this case
2)
HTTP Response Headers
Set-Cookie locka=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie lockb=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie a=2; path=/
4. (The request is not as expected, that value for 'a' had not even
been used in the whole run -we are getting 1)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=1;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the received values, this case 1)
HTTP Response Headers
Set-Cookie locka=1; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
--
Edit this bug report at http://bugs.php.net/?id=37095&edit=1
#37093 [Opn->Fbk]: Daylight Savings Time error
ID: 37093 Updated by: [EMAIL PROTECTED] Reported By: robertsaenz at gmail dot com -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? Previous Comments: [2006-04-15 23:28:04] robertsaenz at gmail dot com Description: The time returned from the date() function is incorrect. The time is an hour behind what it actually should be. This occured after the clocks were set forward an hour. The timezone is: MST and I am in DST territory. The code should explain my problem better. My server is set to use DST and now since our clocks have been set forward (as mentioned before) I've been getting that hour time difference. My work around for now is to set the server's clock an hour ahead which outputs the expected result, however this is not what I want to do. Is there maybe a work around for this. I searched the bugs but didn't find anything that lead to the exact problem I had, but if there is a duplicate I apologize and if you can point me to it that would be great. Thanks. Reproduce code: --- Expected result: 2006-04-15 17:19:55 MST 0 Actual result: -- 2006-04-15 16:19:55 MST 0 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37093 [Fbk->Opn]: Daylight Savings Time error
ID: 37093 User updated by: robertsaenz at gmail dot com Reported By: robertsaenz at gmail dot com -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? Thanks. Previous Comments: [2006-04-16 08:06:56] [EMAIL PROTECTED] >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? [2006-04-15 23:28:04] robertsaenz at gmail dot com Description: The time returned from the date() function is incorrect. The time is an hour behind what it actually should be. This occured after the clocks were set forward an hour. The timezone is: MST and I am in DST territory. The code should explain my problem better. My server is set to use DST and now since our clocks have been set forward (as mentioned before) I've been getting that hour time difference. My work around for now is to set the server's clock an hour ahead which outputs the expected result, however this is not what I want to do. Is there maybe a work around for this. I searched the bugs but didn't find anything that lead to the exact problem I had, but if there is a duplicate I apologize and if you can point me to it that would be great. Thanks. Reproduce code: --- Expected result: 2006-04-15 17:19:55 MST 0 Actual result: -- 2006-04-15 16:19:55 MST 0 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37094 [Opn->Fbk]: a patch to remove cflags from linker commands
ID: 37094 Updated by: [EMAIL PROTECTED] Reported By: glen at delfi dot ee -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: PLD Linux PHP Version: 5.1.2 New Comment: What is exactly the problem you're trying to fix by this patch? Previous Comments: [2006-04-16 00:44:28] glen at delfi dot ee Description: this is purely cosmetic change, as the CFLAGS (include dirs, -DDEFINE-s have no effect at link time), but some compilers might warn that preprocessor flags used at link time. patch against 5.1.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-linkflags-clean.patch and 4.4.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php4-linkflags-clean.patch -- Edit this bug report at http://bugs.php.net/?id=37094&edit=1
#37093 [Opn->Bgs]: Daylight Savings Time error
ID: 37093 Updated by: [EMAIL PROTECTED] Reported By: robertsaenz at gmail dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: Well, I guess using date.timezone INI setting is even easier. But yes, you can use date_default_timezone_set()/_get() either. Previous Comments: [2006-04-16 08:36:49] robertsaenz at gmail dot com Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? Thanks. [2006-04-16 08:06:56] [EMAIL PROTECTED] >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? [2006-04-15 23:28:04] robertsaenz at gmail dot com Description: The time returned from the date() function is incorrect. The time is an hour behind what it actually should be. This occured after the clocks were set forward an hour. The timezone is: MST and I am in DST territory. The code should explain my problem better. My server is set to use DST and now since our clocks have been set forward (as mentioned before) I've been getting that hour time difference. My work around for now is to set the server's clock an hour ahead which outputs the expected result, however this is not what I want to do. Is there maybe a work around for this. I searched the bugs but didn't find anything that lead to the exact problem I had, but if there is a duplicate I apologize and if you can point me to it that would be great. Thanks. Reproduce code: --- Expected result: 2006-04-15 17:19:55 MST 0 Actual result: -- 2006-04-15 16:19:55 MST 0 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37093 [Bgs]: Daylight Savings Time error
ID: 37093 User updated by: robertsaenz at gmail dot com Reported By: robertsaenz at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: I must not be doing something right. I'm trying to do the date.timezone method but for some reason it is not working for me. I'm doing: date.timezone = "US/Mountain" Is there a specific area that it needs to go under php.ini? Or can it just go anywhere in the ini file? I tried it without quotes to no avail. Any help would be great thanks. I'm really trying to avoid having to use the date_default_timezone_set() function. Previous Comments: [2006-04-16 08:41:59] [EMAIL PROTECTED] Well, I guess using date.timezone INI setting is even easier. But yes, you can use date_default_timezone_set()/_get() either. [2006-04-16 08:36:49] robertsaenz at gmail dot com Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? Thanks. [2006-04-16 08:06:56] [EMAIL PROTECTED] >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? [2006-04-15 23:28:04] robertsaenz at gmail dot com Description: The time returned from the date() function is incorrect. The time is an hour behind what it actually should be. This occured after the clocks were set forward an hour. The timezone is: MST and I am in DST territory. The code should explain my problem better. My server is set to use DST and now since our clocks have been set forward (as mentioned before) I've been getting that hour time difference. My work around for now is to set the server's clock an hour ahead which outputs the expected result, however this is not what I want to do. Is there maybe a work around for this. I searched the bugs but didn't find anything that lead to the exact problem I had, but if there is a duplicate I apologize and if you can point me to it that would be great. Thanks. Reproduce code: --- Expected result: 2006-04-15 17:19:55 MST 0 Actual result: -- 2006-04-15 16:19:55 MST 0 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37093 [Bgs]: Daylight Savings Time error
ID: 37093 Updated by: [EMAIL PROTECTED] Reported By: robertsaenz at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: What do you mean by "not working"? Did you restart apache? Did you look in phpinfo() and check that you're modifying the right php.ini file? Previous Comments: [2006-04-16 09:28:03] robertsaenz at gmail dot com I must not be doing something right. I'm trying to do the date.timezone method but for some reason it is not working for me. I'm doing: date.timezone = "US/Mountain" Is there a specific area that it needs to go under php.ini? Or can it just go anywhere in the ini file? I tried it without quotes to no avail. Any help would be great thanks. I'm really trying to avoid having to use the date_default_timezone_set() function. [2006-04-16 08:41:59] [EMAIL PROTECTED] Well, I guess using date.timezone INI setting is even easier. But yes, you can use date_default_timezone_set()/_get() either. [2006-04-16 08:36:49] robertsaenz at gmail dot com Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? Thanks. [2006-04-16 08:06:56] [EMAIL PROTECTED] >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? [2006-04-15 23:28:04] robertsaenz at gmail dot com Description: The time returned from the date() function is incorrect. The time is an hour behind what it actually should be. This occured after the clocks were set forward an hour. The timezone is: MST and I am in DST territory. The code should explain my problem better. My server is set to use DST and now since our clocks have been set forward (as mentioned before) I've been getting that hour time difference. My work around for now is to set the server's clock an hour ahead which outputs the expected result, however this is not what I want to do. Is there maybe a work around for this. I searched the bugs but didn't find anything that lead to the exact problem I had, but if there is a duplicate I apologize and if you can point me to it that would be great. Thanks. Reproduce code: --- Expected result: 2006-04-15 17:19:55 MST 0 Actual result: -- 2006-04-15 16:19:55 MST 0 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37093 [Bgs]: Daylight Savings Time error
ID: 37093 Updated by: [EMAIL PROTECTED] Reported By: robertsaenz at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: You shouldn't use US/Mountain anyway, use one of the America/* listed here: http://www.php.net/manual/en/timezones.america.php Previous Comments: [2006-04-16 09:39:40] [EMAIL PROTECTED] What do you mean by "not working"? Did you restart apache? Did you look in phpinfo() and check that you're modifying the right php.ini file? [2006-04-16 09:28:03] robertsaenz at gmail dot com I must not be doing something right. I'm trying to do the date.timezone method but for some reason it is not working for me. I'm doing: date.timezone = "US/Mountain" Is there a specific area that it needs to go under php.ini? Or can it just go anywhere in the ini file? I tried it without quotes to no avail. Any help would be great thanks. I'm really trying to avoid having to use the date_default_timezone_set() function. [2006-04-16 08:41:59] [EMAIL PROTECTED] Well, I guess using date.timezone INI setting is even easier. But yes, you can use date_default_timezone_set()/_get() either. [2006-04-16 08:36:49] robertsaenz at gmail dot com Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? Thanks. [2006-04-16 08:06:56] [EMAIL PROTECTED] >The timezone is: MST and I am in DST territory. Which means it's actually MDT, not MST. What if you set the correct timezone with date_default_timezone_set() ? 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/37093 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37045 [Asn->Csd]: Fix for #32936 affects valid http redirects
ID: 37045
Updated by: [EMAIL PROTECTED]
Reported By: mberg at synacor dot com
-Status: Assigned
+Status: Closed
Bug Type: Filesystem function related
Operating System: Red Hat Linux 7.2 (ish)
PHP Version: 5.1.2, 4.4.2
Assigned To: iliaa
New Comment:
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.
Previous Comments:
[2006-04-12 14:45:41] [EMAIL PROTECTED]
Ilia, your fix broke this?
[2006-04-11 20:43:09] mberg at synacor dot com
Description:
The original report was a vulnerability in redirects to FTP servers,
since they don't perform URL escaping, but the fix effects HTTP and
HTTPS as well.
This broke one valid redirection for us that we know about.
My fix was to wrap the calls to CHECK_FOR_CNTRL_CHARS in a
conditional:
diff -u2 -r php-4.4.2.orig/ext/standard/http_fopen_wrapper.c
php-4.4.2/ext/standard/http_fopen_wrapper.c
--- php-4.4.2.orig/ext/standard/http_fopen_wrapper.cSun Jan 1
08:46:57 2006
+++ php-4.4.2/ext/standard/http_fopen_wrapper.c Fri Apr 7 18:07:28
2006
@@ -503,7 +503,9 @@
} \
/* check for control characters in login,
password & path */
- CHECK_FOR_CNTRL_CHARS(resource->user)
- CHECK_FOR_CNTRL_CHARS(resource->pass)
- CHECK_FOR_CNTRL_CHARS(resource->path)
+ if (strncasecmp(resource->scheme, "http",
sizeof("http")) && strncasecmp(resource->scheme, "https",
sizeof("https"))) {
+ CHECK_FOR_CNTRL_CHARS(resource->user)
+ CHECK_FOR_CNTRL_CHARS(resource->pass)
+ CHECK_FOR_CNTRL_CHARS(resource->path)
+ }
stream = php_stream_url_wrap_http_ex(NULL,
new_path, mode, options, opened_path, context, --redirect_max, 0
STREAMS_CC TSRMLS_CC);
--
Edit this bug report at http://bugs.php.net/?id=37045&edit=1
#37098 [NEW]: ext/standard/http_fopen_wrapper.c: program cc1 got fatal signal 11
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 5CVS-2006-04-16 (CVS)
PHP Bug Type: Compile Failure
Bug description: ext/standard/http_fopen_wrapper.c: program cc1 got fatal
signal 11
Description:
ilia's fix of
/php-src/ext/standard/http_fopen_wrapper.c
(Fixed bug #37045 (Fixed check for special chars for http redirects).)
Seems to have introduced this problem; If I go to the previous version of
that file, everything compiles fine
Reproduce code:
---
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure; make
Expected result:
Compiles fine.
Actual result:
--
/bin/sh /opt/cruisecontrol/projects/PHP_5_1/php5/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/standard/
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/ -DPHP_ATOM_INC
-I/opt/cruisecontrol/projects/PHP_5_1/php5/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/main
-I/opt/cruisecontrol/projects/PHP_5_1/php5 -I/opt/libxml2/include/libxml2
-I/opt/curl/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/date/lib
-I/usr/include/freetype2 -I/usr/include/c-client -I/usr/include/mysql
-I/opt/postgres/include -I/opt/tidy/include -I/opt/libxslt/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/TSRM
-I/opt/cruisecontrol/projects/PHP_5_1/php5/Zend-I/usr/include -g -O2
-c
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c
-o ext/standard/http_fopen_wrapper.lo
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:
In function `php_stream_url_wrap_http_ex':
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
`newpath' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
(Each undeclared identifier is reported only once
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
for each function it appears in.)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
parse error before `{'
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`l' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`s' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`e' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:644:
`new_path' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:214:
label `out' used but not defined
gcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [ext/standard/http_fopen_wrapper.lo] Error 1
--
Edit bug report at http://bugs.php.net/?id=37098&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37098&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37098&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37098&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37098&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37098&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37098&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37098&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37098&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37098&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37098&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37098&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37098&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37098&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37098&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37098&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37098&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37098&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37098&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37098&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37098&r=mysqlcfg
#37098 [Opn]: ext/standard/http_fopen_wrapper.c: program cc1 got fatal signal 11
ID: 37098
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 5CVS-2006-04-16 (CVS)
New Comment:
For clarification, I'm talking about 1.99.2.10 vs. 1.99.2.11.
Previous Comments:
[2006-04-16 17:26:26] [EMAIL PROTECTED]
Description:
ilia's fix of
/php-src/ext/standard/http_fopen_wrapper.c
(Fixed bug #37045 (Fixed check for special chars for http redirects).)
Seems to have introduced this problem; If I go to the previous version
of that file, everything compiles fine
Reproduce code:
---
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure; make
Expected result:
Compiles fine.
Actual result:
--
/bin/sh /opt/cruisecontrol/projects/PHP_5_1/php5/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/standard/
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/ -DPHP_ATOM_INC
-I/opt/cruisecontrol/projects/PHP_5_1/php5/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/main
-I/opt/cruisecontrol/projects/PHP_5_1/php5
-I/opt/libxml2/include/libxml2 -I/opt/curl/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/date/lib
-I/usr/include/freetype2 -I/usr/include/c-client -I/usr/include/mysql
-I/opt/postgres/include -I/opt/tidy/include -I/opt/libxslt/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/TSRM
-I/opt/cruisecontrol/projects/PHP_5_1/php5/Zend-I/usr/include -g
-O2 -c
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c
-o ext/standard/http_fopen_wrapper.lo
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:
In function `php_stream_url_wrap_http_ex':
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
`newpath' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
(Each undeclared identifier is reported only once
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
for each function it appears in.)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
parse error before `{'
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`l' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`s' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`e' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:644:
`new_path' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:214:
label `out' used but not defined
gcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [ext/standard/http_fopen_wrapper.lo] Error 1
--
Edit this bug report at http://bugs.php.net/?id=37098&edit=1
#37098 [Opn->Csd]: ext/standard/http_fopen_wrapper.c: program cc1 got fatal signal 11
ID: 37098
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 5CVS-2006-04-16 (CVS)
New Comment:
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.
Previous Comments:
[2006-04-16 17:30:14] [EMAIL PROTECTED]
For clarification, I'm talking about 1.99.2.10 vs. 1.99.2.11.
[2006-04-16 17:26:26] [EMAIL PROTECTED]
Description:
ilia's fix of
/php-src/ext/standard/http_fopen_wrapper.c
(Fixed bug #37045 (Fixed check for special chars for http redirects).)
Seems to have introduced this problem; If I go to the previous version
of that file, everything compiles fine
Reproduce code:
---
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure; make
Expected result:
Compiles fine.
Actual result:
--
/bin/sh /opt/cruisecontrol/projects/PHP_5_1/php5/libtool --silent
--preserve-dup-deps --mode=compile gcc -Iext/standard/
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/ -DPHP_ATOM_INC
-I/opt/cruisecontrol/projects/PHP_5_1/php5/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/main
-I/opt/cruisecontrol/projects/PHP_5_1/php5
-I/opt/libxml2/include/libxml2 -I/opt/curl/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/ext/date/lib
-I/usr/include/freetype2 -I/usr/include/c-client -I/usr/include/mysql
-I/opt/postgres/include -I/opt/tidy/include -I/opt/libxslt/include
-I/opt/cruisecontrol/projects/PHP_5_1/php5/TSRM
-I/opt/cruisecontrol/projects/PHP_5_1/php5/Zend-I/usr/include -g
-O2 -c
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c
-o ext/standard/http_fopen_wrapper.lo
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:
In function `php_stream_url_wrap_http_ex':
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
`newpath' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
(Each undeclared identifier is reported only once
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
for each function it appears in.)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:642:
parse error before `{'
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`l' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`s' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:643:
`e' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:644:
`new_path' undeclared (first use in this function)
/opt/cruisecontrol/projects/PHP_5_1/php5/ext/standard/http_fopen_wrapper.c:214:
label `out' used but not defined
gcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [ext/standard/http_fopen_wrapper.lo] Error 1
--
Edit this bug report at http://bugs.php.net/?id=37098&edit=1
#37099 [NEW]: str_replace with arrays - weird behaviour
From: admin at ifyouwantblood dot de Operating system: Linux AND windows PHP version: 5.1.2 PHP Bug Type: Strings related Bug description: str_replace with arrays - weird behaviour Description: str_replace does not replace all array values with the associated array replace. Reproduce code: --- Expected result: gvhg test Actual result: -- gehg tvst -- Edit bug report at http://bugs.php.net/?id=37099&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37099&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37099&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37099&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37099&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37099&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37099&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37099&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37099&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37099&r=support Expected behavior:http://bugs.php.net/fix.php?id=37099&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37099&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37099&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37099&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37099&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37099&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37099&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37099&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37099&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37099&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37099&r=mysqlcfg
#37099 [Opn->Bgs]: str_replace with arrays - weird behaviour
ID: 37099 Updated by: [EMAIL PROTECTED] Reported By: admin at ifyouwantblood dot de -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Linux AND windows PHP Version: 5.1.2 New Comment: The problem is that both of your arrays contain the same characters. So the first str_replace() changes 'e' to 't' and then changes it back when it reaches 't' in the $replace_s array. No bug here, just a user error. Previous Comments: [2006-04-16 18:35:51] admin at ifyouwantblood dot de Description: str_replace does not replace all array values with the associated array replace. Reproduce code: --- Expected result: gvhg test Actual result: -- gehg tvst -- Edit this bug report at http://bugs.php.net/?id=37099&edit=1
#37093 [Bgs]: Daylight Savings Time error
ID: 37093 User updated by: robertsaenz at gmail dot com Reported By: robertsaenz at gmail dot com Status: Bogus Bug Type: Date/time related Operating System: Windows XP Professional PHP Version: 5.1.2 New Comment: What I meant by "not working" was that I am still getting: 2006-04-16 12:19:55 MST 0 When I'm expecting: 2006-04-16 13:19:55 MDT 1 I restarted Apache (which is Apache2 by the way... don't know if it matters but I thought I would throw that in there as extra info). I also stopped it and the started it manually. I even restarted the server and I still get the same result. I'm using the correct php.ini (I just double checked to make sure). The reason I used "US/Mountain" was because it worked with the date_default_timezone_set(). However, I tried "America/Denver" (who is in the same timezone). I got the same result. Previous Comments: [2006-04-16 09:50:16] [EMAIL PROTECTED] You shouldn't use US/Mountain anyway, use one of the America/* listed here: http://www.php.net/manual/en/timezones.america.php [2006-04-16 09:39:40] [EMAIL PROTECTED] What do you mean by "not working"? Did you restart apache? Did you look in phpinfo() and check that you're modifying the right php.ini file? [2006-04-16 09:28:03] robertsaenz at gmail dot com I must not be doing something right. I'm trying to do the date.timezone method but for some reason it is not working for me. I'm doing: date.timezone = "US/Mountain" Is there a specific area that it needs to go under php.ini? Or can it just go anywhere in the ini file? I tried it without quotes to no avail. Any help would be great thanks. I'm really trying to avoid having to use the date_default_timezone_set() function. [2006-04-16 08:41:59] [EMAIL PROTECTED] Well, I guess using date.timezone INI setting is even easier. But yes, you can use date_default_timezone_set()/_get() either. [2006-04-16 08:36:49] robertsaenz at gmail dot com Oops! Sorry meant to say MDT and I should have expected MDT but I didn't put that down, nor did I put a 1 expected for DST in expected result. Yeah using date_default_timezone_set() worked. Is there a way to change this permanently or do I have to do this for every script that uses the date function? 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/37093 -- Edit this bug report at http://bugs.php.net/?id=37093&edit=1
#37097 [Asn]: PDO-MSSQL converts bigint to float.
ID: 37097
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5.1.3RC2
Assigned To: wez
New Comment:
FYI: You should use PDO ODBC on Windows.
Previous Comments:
[2006-04-16 07:57:49] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-04-16 07:44:32] stochnagara at hotmail dot com
Description:
PDO MsSql driver returns bigint values as float instead of int.
They are always formated as .0
Reproduce code:
---
CREATE TABLE demo (
bi bigint not null,
sm int null
);
insert into demo (1,1);
$result = $pdo->query ("SELECT * FROM demo")->fetch();
echo "bi={$result['bi']};"
echo "sm={$result['sm']};"
Expected result:
bi=1;sm=1;
Actual result:
--
bi=1.0;sm=1;
--
Edit this bug report at http://bugs.php.net/?id=37097&edit=1
#37100 [NEW]: data is returned truncated with BINARY CURSOR
From: e dot mauviere at geoclip dot fr
Operating system: WIN XP PRO
PHP version: 5.1.2
PHP Bug Type: PostgreSQL related
Bug description: data is returned truncated with BINARY CURSOR
Description:
Impossible to retrieve properly binary data from a binary field in
Postgresql.
It should work with the SQL BINARY CURSOR OPTION in Postgres, but data
returned is truncated.
Reproduce code:
---
CREATE TABLE test(binfield byteA) ;
INSERT INTO test VALUES (decode('0103AA000812','hex'));
//First try
$data =pg_query("SELECT binfield FROM test");
$res=pg_fetch_result($data,0);
echo $res; // =>"\001\003\252\000\010\022"
echo bin2hex(pg_unescape_bytea($res)); //=> "0103aa000812"
//By default, Potsgresql returns binary field values as strings, so we
need to unescape them to restore original binary data. Tedious.
Performance issue here.
//second try
$sql="BEGIN;DECLARE mycursor BINARY CURSOR FOR SELECT binfield FROM
test;fetch all in mycursor;";
//the BINARY CURSOR option forces PostgreSQ to return binary data
$data =pg_query($sql);
$res=pg_fetch_result($data,0);
echo strlen($res); //=> 3
echo bin2hex($res); //=> 0103aa
//BUG : data returned is truncated, as soon as a "00" byte is encountered,
Expected result:
i am expecting to retrieve full binary content
--
Edit bug report at http://bugs.php.net/?id=37100&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37100&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=37100&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37100&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37100&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37100&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37100&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37100&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37100&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37100&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37100&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37100&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37100&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37100&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37100&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37100&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37100&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37100&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37100&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37100&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37100&r=mysqlcfg
#37088 [WFx]: Universalize needle/haystack argument order
ID: 37088 User updated by: bugzilla at yakasha dot net Reported By: bugzilla at yakasha dot net Status: Wont fix Bug Type: Feature/Change Request Operating System: * PHP Version: * New Comment: Wow. What an amazingly helpful response. You're great. Yes, yes, we should all just change our ides to cope with php's limitations and retardedness. And whenever php has a problem in a certain area, we should just use exec() to run a perl script right? Or maybe, just maybe, you could accept suggestions on how to improve the language, think about those suggestions, and discuss with the suggestor as to why you would not want to do something intelligent to make php better. Previous Comments: [2006-04-14 20:27:09] [EMAIL PROTECTED] Use a decent IDE then. [2006-04-14 19:34:51] bugzilla at yakasha dot net Description: Please universalize the argument ordering for search functions like strstr & in_array. It's annoying to have to constantly second guess myself, "Which uses needle/haystack and which is haystack/needle" Reproduce code: --- Expected result: String: found Array: found Actual result: -- String: not found Array: found -- Edit this bug report at http://bugs.php.net/?id=37088&edit=1
#37100 [Opn->Asn]: data is returned truncated with BINARY CURSOR
ID: 37100
Updated by: [EMAIL PROTECTED]
Reported By: e dot mauviere at geoclip dot fr
-Status: Open
+Status: Assigned
Bug Type: PostgreSQL related
Operating System: WIN XP PRO
PHP Version: 5.1.2
-Assigned To:
+Assigned To: helly
New Comment:
Marcus, please test the patch:
http://tony2001.phpclub.net/dev/tmp/bug37100.diff
I don't have/use PG, so unfortunately I can't do it myself.
Previous Comments:
[2006-04-16 20:32:21] e dot mauviere at geoclip dot fr
Description:
Impossible to retrieve properly binary data from a binary field in
Postgresql.
It should work with the SQL BINARY CURSOR OPTION in Postgres, but data
returned is truncated.
Reproduce code:
---
CREATE TABLE test(binfield byteA) ;
INSERT INTO test VALUES (decode('0103AA000812','hex'));
//First try
$data =pg_query("SELECT binfield FROM test");
$res=pg_fetch_result($data,0);
echo $res; // =>"\001\003\252\000\010\022"
echo bin2hex(pg_unescape_bytea($res)); //=> "0103aa000812"
//By default, Potsgresql returns binary field values as strings, so we
need to unescape them to restore original binary data. Tedious.
Performance issue here.
//second try
$sql="BEGIN;DECLARE mycursor BINARY CURSOR FOR SELECT binfield FROM
test;fetch all in mycursor;";
//the BINARY CURSOR option forces PostgreSQ to return binary data
$data =pg_query($sql);
$res=pg_fetch_result($data,0);
echo strlen($res); //=> 3
echo bin2hex($res); //=> 0103aa
//BUG : data returned is truncated, as soon as a "00" byte is
encountered,
Expected result:
i am expecting to retrieve full binary content
--
Edit this bug report at http://bugs.php.net/?id=37100&edit=1
#37095 [Fbk->Opn]: cookie returns random value
ID: 37095
User updated by: giaym at hotmail dot com
Reported By: giaym at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Windows 2000
PHP Version: 5.1.2
New Comment:
Both IE6 and Firefox? Although what you say makes sense phpinfo shows
php doing the right thing. This would be a php bug only if phpinfo()
was returning the wrong data, which is unlikely.
Previous Comments:
[2006-04-16 07:59:25] [EMAIL PROTECTED]
So, your browser sends wrong data to PHP script, am I correct? Why do
you report it to PHP bug system then?
[2006-04-16 02:18:33] giaym at hotmail dot com
Oh, same behavior for IE6. The server is located on the same machine as
the browser.
[2006-04-16 02:14:59] giaym at hotmail dot com
Description:
Randomly, the cookies send back random values to the server, values
different than those set the previous page load.
I use session auto start on php.ini. PHP runs on Apache 2.
Reproduce code:
---
a, b, locka and lockb are cookies set with setcookie(, ,
0, "/");
if($somevar == "lock") {
echo "lock";
Set cookies locka and lockb with the values of cookies a and b
respectively.
} else if($somevar == "random") {
echo "random";
Delete locka and lockb, and give a random value to a.
} else {
echo "none";
if(locka not set) Set random value to a.
}
if (b not set) Set random value to b.
Enter pages in that order:
www.domain.com/page/
www.domain.com/page/lock/
www.domain.com/page/random/
www.domain.com/page/lock/
(The if logic works, this is not a case of $somevar holding an
incorrect value.)
Expected result:
www.domain.com/page/
received cookies: none
output: none
sent cookies: a with value x; b with value y
www.domain.com/page/lock/
received cookies: a with value x
output: lock
sent cookies: lock a = x; lock b = y
www.domain.com/page/random/
received cookies: a with value x; b with value y; locka with value x;
lockb with value y
output: random
sent cookies: delete lock a; delete lock b; a = z
www.domain.com/page/lock/
received cookies: a with value z; b with value y
output: lock
sent cookies: lock a = z; lock b = y
Actual result:
--
Everything as expected except the last page load: The cookie received
isn't a = z, it is a = q, I mean, another value. The server then sends
"lock a = q" following the logic.
PHPSESSID is received and reset on every page load.
1.
HTTP Request Headers
HTTP RequestGET /page/ HTTP/1.1
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2)
Gecko/20060308 Firefox/1.5.0.2
HTTP Response Headers
Set-Cookie PHPSESSID=3fo392aek7m274550d9oppqdo6; path=/
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma no-cache
Set-Cookie a=3; path=/
Set-Cookie b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
2. (The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the values of a and b)
HTTP Response Headers
Set-Cookie locka=3; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
3.(The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/random/ HTTP/1.1
Cookie
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52;
locka=3;
lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We delete the locked values and set a random value for a, this case
2)
HTTP Response Headers
Set-Cookie locka=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie lockb=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie a=2; path=/
4. (The request is not as expected, that value for 'a' had not even
been used in the whole run -we are getting 1)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=1;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the received values, this case 1)
HTTP Response Headers
Set-Cookie locka=1; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
--
Edit this bug report at http://bugs.php.net/?id=37095&edit=1
#37095 [Opn->Csd]: cookie returns random value
ID: 37095
User updated by: giaym at hotmail dot com
Reported By: giaym at hotmail dot com
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Windows 2000
PHP Version: 5.1.2
New Comment:
Closing.
Previous Comments:
[2006-04-16 22:28:57] giaym at hotmail dot com
Both IE6 and Firefox? Although what you say makes sense phpinfo shows
php doing the right thing. This would be a php bug only if phpinfo()
was returning the wrong data, which is unlikely.
[2006-04-16 07:59:25] [EMAIL PROTECTED]
So, your browser sends wrong data to PHP script, am I correct? Why do
you report it to PHP bug system then?
[2006-04-16 02:18:33] giaym at hotmail dot com
Oh, same behavior for IE6. The server is located on the same machine as
the browser.
[2006-04-16 02:14:59] giaym at hotmail dot com
Description:
Randomly, the cookies send back random values to the server, values
different than those set the previous page load.
I use session auto start on php.ini. PHP runs on Apache 2.
Reproduce code:
---
a, b, locka and lockb are cookies set with setcookie(, ,
0, "/");
if($somevar == "lock") {
echo "lock";
Set cookies locka and lockb with the values of cookies a and b
respectively.
} else if($somevar == "random") {
echo "random";
Delete locka and lockb, and give a random value to a.
} else {
echo "none";
if(locka not set) Set random value to a.
}
if (b not set) Set random value to b.
Enter pages in that order:
www.domain.com/page/
www.domain.com/page/lock/
www.domain.com/page/random/
www.domain.com/page/lock/
(The if logic works, this is not a case of $somevar holding an
incorrect value.)
Expected result:
www.domain.com/page/
received cookies: none
output: none
sent cookies: a with value x; b with value y
www.domain.com/page/lock/
received cookies: a with value x
output: lock
sent cookies: lock a = x; lock b = y
www.domain.com/page/random/
received cookies: a with value x; b with value y; locka with value x;
lockb with value y
output: random
sent cookies: delete lock a; delete lock b; a = z
www.domain.com/page/lock/
received cookies: a with value z; b with value y
output: lock
sent cookies: lock a = z; lock b = y
Actual result:
--
Everything as expected except the last page load: The cookie received
isn't a = z, it is a = q, I mean, another value. The server then sends
"lock a = q" following the logic.
PHPSESSID is received and reset on every page load.
1.
HTTP Request Headers
HTTP RequestGET /page/ HTTP/1.1
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2)
Gecko/20060308 Firefox/1.5.0.2
HTTP Response Headers
Set-Cookie PHPSESSID=3fo392aek7m274550d9oppqdo6; path=/
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma no-cache
Set-Cookie a=3; path=/
Set-Cookie b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
2. (The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the values of a and b)
HTTP Response Headers
Set-Cookie locka=3; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
3.(The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/random/ HTTP/1.1
Cookie
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52;
locka=3;
lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We delete the locked values and set a random value for a, this case
2)
HTTP Response Headers
Set-Cookie locka=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie lockb=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie a=2; path=/
4. (The request is not as expected, that value for 'a' had not even
been used in the whole run -we are getting 1)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=1;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the received values, this case 1)
HTTP Response Headers
Set-Cookie locka=1; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
--
Edit this bug report at http://bugs.php.net/?id=37095&edit=1
#37095 [Csd->Bgs]: cookie returns random value
ID: 37095
Updated by: [EMAIL PROTECTED]
Reported By: giaym at hotmail dot com
-Status: Closed
+Status: Bogus
Bug Type: Session related
Operating System: Windows 2000
PHP Version: 5.1.2
New Comment:
No bug -> bogus.
Feel free to reopen the report when/if you have more info.
Previous Comments:
[2006-04-16 22:30:24] giaym at hotmail dot com
Closing.
[2006-04-16 22:28:57] giaym at hotmail dot com
Both IE6 and Firefox? Although what you say makes sense phpinfo shows
php doing the right thing. This would be a php bug only if phpinfo()
was returning the wrong data, which is unlikely.
[2006-04-16 07:59:25] [EMAIL PROTECTED]
So, your browser sends wrong data to PHP script, am I correct? Why do
you report it to PHP bug system then?
[2006-04-16 02:18:33] giaym at hotmail dot com
Oh, same behavior for IE6. The server is located on the same machine as
the browser.
[2006-04-16 02:14:59] giaym at hotmail dot com
Description:
Randomly, the cookies send back random values to the server, values
different than those set the previous page load.
I use session auto start on php.ini. PHP runs on Apache 2.
Reproduce code:
---
a, b, locka and lockb are cookies set with setcookie(, ,
0, "/");
if($somevar == "lock") {
echo "lock";
Set cookies locka and lockb with the values of cookies a and b
respectively.
} else if($somevar == "random") {
echo "random";
Delete locka and lockb, and give a random value to a.
} else {
echo "none";
if(locka not set) Set random value to a.
}
if (b not set) Set random value to b.
Enter pages in that order:
www.domain.com/page/
www.domain.com/page/lock/
www.domain.com/page/random/
www.domain.com/page/lock/
(The if logic works, this is not a case of $somevar holding an
incorrect value.)
Expected result:
www.domain.com/page/
received cookies: none
output: none
sent cookies: a with value x; b with value y
www.domain.com/page/lock/
received cookies: a with value x
output: lock
sent cookies: lock a = x; lock b = y
www.domain.com/page/random/
received cookies: a with value x; b with value y; locka with value x;
lockb with value y
output: random
sent cookies: delete lock a; delete lock b; a = z
www.domain.com/page/lock/
received cookies: a with value z; b with value y
output: lock
sent cookies: lock a = z; lock b = y
Actual result:
--
Everything as expected except the last page load: The cookie received
isn't a = z, it is a = q, I mean, another value. The server then sends
"lock a = q" following the logic.
PHPSESSID is received and reset on every page load.
1.
HTTP Request Headers
HTTP RequestGET /page/ HTTP/1.1
User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.2)
Gecko/20060308 Firefox/1.5.0.2
HTTP Response Headers
Set-Cookie PHPSESSID=3fo392aek7m274550d9oppqdo6; path=/
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma no-cache
Set-Cookie a=3; path=/
Set-Cookie b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
2. (The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the values of a and b)
HTTP Response Headers
Set-Cookie locka=3; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
3.(The request is as expected)
HTTP Request Headers
HTTP RequestGET /page/random/ HTTP/1.1
Cookie
a=3;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52;
locka=3;
lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We delete the locked values and set a random value for a, this case
2)
HTTP Response Headers
Set-Cookie locka=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie lockb=deleted; expires=Sat, 16-Apr-2005 01:33:24 GMT;
path=/
Set-Cookie a=2; path=/
4. (The request is not as expected, that value for 'a' had not even
been used in the whole run -we are getting 1)
HTTP Request Headers
HTTP RequestGET /page/lock/ HTTP/1.1
a=1;
b=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52
(We lock the received values, this case 1)
HTTP Response Headers
Set-Cookie locka=1; path=/
Set-Cookie lockb=91-5-177-39-4-61-87-25-1-42-0-50-64-5-164-52; path=/
--
Edit this bug report at http://bugs.php.net/?id=37095&edit=1
#37101 [NEW]: Cannot compile with HAVE_LOG1P undefined in php_config.h
From: vap at vap dot name Operating system: Linux with uClibc 0.9.27 PHP version: 5.1.2 PHP Bug Type: Compile Failure Bug description: Cannot compile with HAVE_LOG1P undefined in php_config.h Description: I was trying to compile php 5.1.2 for my embedded device, running uClibc C library instead of glibc. ./configure in uClibc-based system produces a configuration with HAVE_LOG1P undefined in php_config.h, and in this circumstances compilation fails - it cannot find zif_log1p symbol at link time. Problem is caused by PHP_FE(log1p,NULL) not properly ifdefed with HAVE_LOG1P macro in php-5.1.2/ext/standard/basic_functions.c. This tiny patch helps: http://vap.name/tmp/php_5_1_2_have_log1p.patch -- Edit bug report at http://bugs.php.net/?id=37101&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37101&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37101&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37101&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37101&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37101&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37101&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37101&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37101&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37101&r=support Expected behavior:http://bugs.php.net/fix.php?id=37101&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37101&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37101&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37101&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37101&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37101&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37101&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37101&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37101&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37101&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37101&r=mysqlcfg
#37094 [Fbk->Opn]: a patch to remove cflags from linker commands
ID: 37094 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee -Status: Feedback +Status: Open Bug Type: *Compile Issues Operating System: PLD Linux PHP Version: 5.1.2 New Comment: cleaning up. Previous Comments: [2006-04-16 08:37:04] [EMAIL PROTECTED] What is exactly the problem you're trying to fix by this patch? [2006-04-16 00:44:28] glen at delfi dot ee Description: this is purely cosmetic change, as the CFLAGS (include dirs, -DDEFINE-s have no effect at link time), but some compilers might warn that preprocessor flags used at link time. patch against 5.1.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php-linkflags-clean.patch and 4.4.2: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/php4-linkflags-clean.patch -- Edit this bug report at http://bugs.php.net/?id=37094&edit=1
