#48924 [Asn]: int value PHP_INT_MAX causes Invalid text representation in pdo_pgsql

2009-07-16 Thread mark dot kirkwood at catalyst dot net dot nz
 ID:   48924
 User updated by:  mark dot kirkwood at catalyst dot net dot nz
 Reported By:  mark dot kirkwood at catalyst dot net dot nz
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Ubuntu x86 (32 bit)
 PHP Version:  5.2CVS-2009-07-14 (CVS)
 Assigned To:  felipe
 New Comment:

Rechecked at home on a 32 bit os, and confirmed that your patch fixes
the issue. Nice work, and thanks again for a very fast resolution.


Previous Comments:


[2009-07-16 01:24:13] mark dot kirkwood at catalyst dot net dot nz

Hmm - if you are getting out of range, then that sounds like your table
has the wrong definition - it should be created by:

CREATE TABLE a (id bigint)

so that 2147483648 can actually be inserted. I can replicate what you
are seeing by creating a with 'id integer'.

Having said that, it looks to me like your patch fixes the problem, but
I only have a 64 bit system here at work, so I'm cheating by doing:

//$id = PHP_INT_MAX + 1;
$id = (float)2147483648;

I'll check on a 32-bit system tonight to be sure and report back.
Thanks for the fast response!



[2009-07-16 01:07:23] fel...@php.net

Yes, it's 32 bit OS.
I just got an expected error out of range.

I've commited a patch [1] that remove the trailing zeros, please let me
know if it fixes your case.

About the HEAD version, It currently doesn't contains the fix (the code
which introduced the trailing zeros) for #41698.

[1] http://felipe.ath.cx/diff/bug48924.diff



[2009-07-15 23:24:17] mark dot kirkwood at catalyst dot net dot nz

Are you using a 32bit os? If you turn on statement logging you should
see an insert that looks like:

INSERT INTO a VALUES('2147483648.00')



[2009-07-15 23:14:38] fel...@php.net

I can't reproduce it on PostgreSQL with libpq5 (8.3.7).



[2009-07-15 00:38:19] mark dot kirkwood at catalyst dot net dot nz

Re: my footnote for Mysql - actually it does *not* elicit a similar
error with strict mode on.Sorry, my confusion.



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/48924

-- 
Edit this bug report at http://bugs.php.net/?id=48924edit=1



#48924 [Asn]: int value PHP_INT_MAX causes Invalid text representation in pdo_pgsql

2009-07-15 Thread mark dot kirkwood at catalyst dot net dot nz
 ID:   48924
 User updated by:  mark dot kirkwood at catalyst dot net dot nz
 Reported By:  mark dot kirkwood at catalyst dot net dot nz
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Ubuntu x86 (32 bit)
 PHP Version:  5.2CVS-2009-07-14 (CVS)
 Assigned To:  felipe
 New Comment:

Hmm - if you are getting out of range, then that sounds like your table
has the wrong definition - it should be created by:

CREATE TABLE a (id bigint)

so that 2147483648 can actually be inserted. I can replicate what you
are seeing by creating a with 'id integer'.

Having said that, it looks to me like your patch fixes the problem, but
I only have a 64 bit system here at work, so I'm cheating by doing:

//$id = PHP_INT_MAX + 1;
$id = (float)2147483648;

I'll check on a 32-bit system tonight to be sure and report back.
Thanks for the fast response!


Previous Comments:


[2009-07-16 01:07:23] fel...@php.net

Yes, it's 32 bit OS.
I just got an expected error out of range.

I've commited a patch [1] that remove the trailing zeros, please let me
know if it fixes your case.

About the HEAD version, It currently doesn't contains the fix (the code
which introduced the trailing zeros) for #41698.

[1] http://felipe.ath.cx/diff/bug48924.diff



[2009-07-15 23:24:17] mark dot kirkwood at catalyst dot net dot nz

Are you using a 32bit os? If you turn on statement logging you should
see an insert that looks like:

INSERT INTO a VALUES('2147483648.00')



[2009-07-15 23:14:38] fel...@php.net

I can't reproduce it on PostgreSQL with libpq5 (8.3.7).



[2009-07-15 00:38:19] mark dot kirkwood at catalyst dot net dot nz

Re: my footnote for Mysql - actually it does *not* elicit a similar
error with strict mode on.Sorry, my confusion.



[2009-07-14 23:23:05] mark dot kirkwood at catalyst dot net dot nz

Patch - merging the change from 6.0 to 5.2 (or 5.3 for that matter):
*** ext/pdo/pdo_stmt.c.orig 2009-07-14 18:07:23.0 +1200
--- ext/pdo/pdo_stmt.c  2009-07-15 11:20:58.0 +1200
***
*** 327,339 
}

if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_STR 
param-max_value_len = 0  ! ZVAL_IS_NULL(param-parameter)) {
!   if (Z_TYPE_P(param-parameter) == IS_DOUBLE) {
!   char *p;
!   int len = spprintf(p, 0, %F,
Z_DVAL_P(param-parameter));
!   ZVAL_STRINGL(param-parameter, p, len, 0);
!   } else {
!   convert_to_string(param-parameter);
!   }
} else if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_INT 
Z_TYPE_P(param-parameter) == IS_BOOL) {
convert_to_long(param-parameter);
} else if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_BOOL 
Z_TYPE_P(param-parameter) == IS_LONG) {
--- 327,333 
}

if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_STR 
param-max_value_len = 0  ! ZVAL_IS_NULL(param-parameter)) {
!   convert_to_string(param-parameter);
} else if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_INT 
Z_TYPE_P(param-parameter) == IS_BOOL) {
convert_to_long(param-parameter);
} else if (PDO_PARAM_TYPE(param-param_type) == PDO_PARAM_BOOL 
Z_TYPE_P(param-parameter) == IS_LONG) {



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/48924

-- 
Edit this bug report at http://bugs.php.net/?id=48924edit=1