[wp-hackers] $wpdb->prepare and %d for integers

[Dion Hulse (dd32)]

Quite simply, %d treats the value as a Integer. Integers in PHP do not
contain commas, 0-9 are the expected values. PHP's internal
String->Integer parsing code uses the first 0-9. segment of the number
as the final value.

Eg:
$in = '123,456.789';
printf('%d', $in); //123
var_dump( (int)$in ); //123

$in = '123456.789';
printf('%d', $in); //123456
var_dump( (int)$in ); //123456

The PHP documentation does indeed specify, that %d is a decimal.. but
that's just not the case.. It's an Integer.

PHP's closest thing to a Decimal is the Float data type:
$in = '123456.789'; // Note: commas will return 123 again.

printf('%f', $in); //123456.789000
var_dump( (float)$in ); //float 123456.789

the WPDB Class only specifies %s and %d as valid placeholders, but i
don't see any code which restricts it to that, so you might be able to
use %f to represent decimals (as floats, which remember, are less
accurate than a decimal)

On 15 August 2011 11:36, 24/7 <24-7 at gmx.net> wrote:
> As to the description of the *%d type specifier* for *sprintf* in the php
> manual <http://php.net/manual/en/function.sprintf.php>, *%d* should be "*d -
> the argument is treated as an integer, and presented as a (signed) decimal
> number.*". I run into the problem that using *$wpdb->update* along with the
> *$format* and *%d* removed all values behind the comma (or "ceiled" them?).
> It took me ages to find that problem and so I had to insert strings into *double
> *columns as a work around.
>
> I wanted to open a ticket about that, but I couldn't really get behind the
> reason why this happens (and ran out of time). Is there anyone who knows
> what exactly is responsible for this behavior - as this is (imo) a bug?
>
> Best wishes,
> K.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
>