[wp-trac] [WordPress Trac] #24884: WP_Query's "m" parameter is cast to an int which is a problem due to 32-bit signed intergers

[WordPress Trac]

#24884: WP_Query's "m" parameter is cast to an int which is a problem due to 32-bit
signed intergers
--------------------------+------------------------------
 Reporter:  Viper007Bond  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:  3.5.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------
Description changed by Viper007Bond:

Old description:

> `WP_Query`'s `m` parameter accepts MySQL datetimes basically. These
> values can be up to 14 characters long (YYYYMMDDHHMMSS). For the long
> values, you end up with
> [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing
> 2147483647] when the passed value is run through `absint()`. While in the
> process of being used to create a query, it is further validated by being
> run through `preg_replace( '|[^0-9]|', '', $q['m'] )` which makes the
> integer casting redundant.
>
> Attached is a patch that fixes this issue by just using regex to validate
> the value.
>
> I discovered this while writing unit tests for #18694 and which the patch
> on this ticket applied, the unit tests now work as expected. This is
> another case of unit tests saving the day! :)

New description:

 `WP_Query`'s `m` parameter accepts MySQL datetimes basically. These values
 can be up to 14 characters long (YYYYMMDDHHMMSS). For the long values, you
 end up with
 [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing
 2147483647] when the passed value is run through `absint()`. While in the
 process of being used to create a query, it is further validated by being
 run through `preg_replace( '|[^0-9]|', '', $q['m'] )` which makes the
 integer casting redundant.

 Attached is a patch that fixes this issue by just using regex to validate
 the value.

 I discovered this while writing unit tests for #18694 and with the patch
 on this ticket applied, the unit tests now work as expected. This is
 another case of unit tests saving the day! :)

--

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24884#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software