lib: coerce -0 to +0 in various APIs#63556
Conversation
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
|
Review requested:
|
| validateUint32(interval, 'interval'); | ||
| // Coerce -0 to +0. | ||
| interval += 0; |
There was a problem hiding this comment.
Shouldn't we update validateUint32 to reject -0 instead?
There was a problem hiding this comment.
I have no particular sympathy for either or.
There was a problem hiding this comment.
Having it part of the helper is probably more robust than relying on humans to remember for checking for -0
There was a problem hiding this comment.
Having it part of the helper is probably more robust than relying on humans to remember for checking for
-0
Maybe even have it part of all uint conversion helpers?
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #63556 +/- ##
==========================================
+ Coverage 90.31% 90.34% +0.02%
==========================================
Files 730 730
Lines 234161 234414 +253
Branches 43917 43930 +13
==========================================
+ Hits 211486 211784 +298
+ Misses 14408 14376 -32
+ Partials 8267 8254 -13
🚀 New features to boost your workflow:
|
Followup to #63531
This is not an exhaustive list of these occurences, just the ones I can remotely imagine being exposed to an untrusted used input through a web-based or CLI interface.
The tests demonstrate the process crashing before the
./libchanges.I used Codex to find and confirm these before diving in.