peczenyj / GDPR-IAB-TCFv2 / 25463258306

96%

main: 96%

push

github

fix: avoid 32-bit IV overflow when decoding 36-bit timestamps (#55)

TCF v2 stores Created and LastUpdated as a 36-bit deciseconds-since-
epoch field, which exceeds a 32-bit signed IV (max 2^31 - 1 ≈ 2.15e9).
On a Perl built without 64-bit integer support (use64bitint=undef,
ivsize=4 -- e.g. armv6l-linux smokers running on Raspberry Pi), the
BitUtils get_uint36 fallback already returns the value as an NV via
Math::BigInt->numify, but the file-level `use integer` in
GDPR::IAB::TCFv2 was forcing the subsequent `/ 10` and `% 10` in
_get_epoch to coerce that NV back to a 32-bit IV, overflowing the
intermediate result.

Symptom on the affected smoker (CPAN Testers 3e3e8fca-4988-...):

    $consent->created       => 0           (expected 1228644257)
    ($consent->last_updated)[1] => -100000000 (expected 700000000)

The -100000000 is the smoking gun: it can only come from
(-1) * 100_000_000, which means `% 10` was evaluated under
C-integer semantics on a clamped float-to-int conversion.

Fix: drop `use integer` for the scope of _get_epoch and reformulate
the modulo as `($deciseconds - $seconds * 10) * 1e8` so the math
stays in NV-land. 36 bits fits losslessly in NV's 53-bit mantissa,
and `int()` lands the correct integer at the end without ever
converting an out-of-range NV to a 32-bit IV.

Add a regression test in t/12-bigint-fallback.t that forces the
fallback path (CAN_PACK_QUADS=0) and asserts the spec-correct
timestamps for the standard fixture in both scalar and list context,
so the bug is caught on 64-bit smokers too.

4 of 4 new or added lines in 1 file covered. (100.0%)

744 of 778 relevant lines covered (95.63%)

11588.09 hits per line