Steve Lhomme pushed to branch master at VideoLAN / VLC
Commits:
a632b0df by Romain Vimont at 2023-01-23T15:01:48+00:00
compat: fix jrand48()
According to the manpage, jrand48() must return a signed long integer
uniformly distributed over the interval [-2^31, 2^31).
The old implementation first computed iterate48(), which returns a
positive 48-bit integer (as 'uint64_t', then cast to
'int64_t'). Once
right-shifted by 16 bits, the result is guaranteed to be a 32-bit
positive integer as 'int64_t'.
It is then (implicitly) cast to 'long' to match the return type.
When the 32th bit is 0 (i.e. the value fits in 31-bit), then everything
is ok. However, when the 32nd bit is 1, then there are two cases (which
are both incorrect):
- if the 'long' type is 32-bit on the platform, then conversion from
'int64_t' to 'long' is undefined;
- if the 'long' type is more than 32-bit, then the resulting value will
be a positive integer in the interval [0, 2^32), whereas jrand48()
must return a value in the interval [-2^31, 2^31).
- - - - -
1 changed file:
- compat/nrand48.c
Changes:
=====================================
compat/nrand48.c
=====================================
@@ -53,7 +53,12 @@ double erand48 (unsigned short subi[3])
long jrand48 (unsigned short subi[3])
{
- return ((int64_t)iterate48 (subi)) >> 16;
+ union {
+ uint32_t u;
+ int32_t i;
+ } v;
+ v.u = iterate48(subi) >> 16;
+ return v.i;
}
long nrand48 (unsigned short subi[3])
View it on GitLab:
https://code.videolan.org/videolan/vlc/-/commit/a632b0dfe2a99a46055caf6cc945f6dd366433f4
--
View it on GitLab:
https://code.videolan.org/videolan/vlc/-/commit/a632b0dfe2a99a46055caf6cc945f6dd366433f4
You're receiving this email because of your account on code.videolan.org.
VideoLAN code repository instance_______________________________________________
vlc-commits mailing list
vlc-commits@videolan.org
https://mailman.videolan.org/listinfo/vlc-commits
