[wp-trac] [WordPress Trac] #46346: Page counts and related calculations typically expect and document ints but are actually floats
WordPress Trac
noreply at wordpress.org
Thu Mar 4 01:27:28 UTC 2021
#46346: Page counts and related calculations typically expect and document ints but
are actually floats
----------------------------------------+-------------------------------
Reporter: lev0 | Owner: SergeyBiryukov
Type: defect (bug) | Status: reviewing
Priority: normal | Milestone: 5.8
Component: General | Version:
Severity: minor | Resolution:
Keywords: has-patch needs-unit-tests | Focuses: coding-standards
----------------------------------------+-------------------------------
Comment (by lev0):
* I'm not married to the name at all, I'm sure there's a better choice,
perhaps something generic about splitting into groups.
* I totally get your point of about it not being guaranteed to return a
float and I'm fully aware that's what the last patch does. I took your
previous feedback about the (albeit uncommon) potential for the number to
be greater than `PHP_INT_MAX` which is why I submitted code that
deliberately avoids casting. If you feed it ints/int-like strings (as
documented) it gives you an int unless an input is outside the range PHP
can store. As it is being fed these input types in the core code, so
should the return be as expected.
* I don't understand your point about wrapping `ceil` in `round`, my
understanding is that [https://3v4l.org/vuJJL this is a no-op] because
they both return floats.
* I know how `/` works, which is why I've suggested from the beginning
that the operation should be gently coerced into producing an int by
giving it ints and ensuring no remainder.
* As stated previously "This patch is not intended to guard against bad
input (and nor does the current version)". WordPress already prevents most
division by zero where the `ceil( $x / $y )`-style calls are currently.
The same exceptions and errors can be thrown from the current code.
* I didn't feel this change would have any success if it introduced a
dependency on bcmath; I don't see any use of it in core currently (correct
me if I'm wrong). If WordPress deems introducing it to be a good idea,
that's fine.
* You bring up many points about casting to an integer but also that this
may not be desirable in case of overflow, which I agree with. Hence this
patch is, as it was, intended to produce an int ''by default'', not
corrupt data. I think this causes the least disruption.
I put what I thought was a more concise function in the last patch but it
could be (a little uglier) as before to reduce that slim chance of
overflow:
{{{#!patch
Index: wp-includes/functions.php
===================================================================
--- wp-includes/functions.php (revision 50096)
+++ wp-includes/functions.php (working copy)
@@ -7866,3 +7866,22 @@
function wp_fuzzy_number_match( $expected, $actual, $precision = 1 ) {
return abs( (float) $expected - (float) $actual ) <= $precision;
}
+
+/**
+ * Calculate the number of pages a set of results can be split into.
+ *
+ * This is similar to using `ceil()` on division but returns an integer.
+ *
+ * @since 5.8.0
+ *
+ * @param int $total_items The count of items to paginate.
+ * @param int $per_page The maximum number of items per page.
+ * @return int The total number of pages.
+ */
+function wp_total_pages( $total_items, $per_page ) {
+ $remainder = $total_items % $per_page;
+ if ( $remainder ) {
+ return 1 + ( ( $total_items - $remainder ) / $per_page );
+ }
+ return $total_items / $per_page;
+}
}}}
I deliberately didn't submit this via GitHub as I figured I'd get feedback
here about whatever else needed to be included, test-wise, etc. to make it
worthwhile. I can submit it there instead if that is preferred.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/46346#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list