Just as with autotools it may not test the actual compat version of a function,
but the one provided by the toolchain. That allows validating the tests
with the real thing.
The computed value was incorrect for types smaller than long long. The
code is not really used by anything at the moment, since we pretty much
compile with Clang or GCC only.
This only implements unsigned types for now, as there are no known use
cases for signed checked arithmetic as of yet. The macros will safely
error out at compilation time if signed types are misused.
When compiling with the GDK the POSIX variants are defined but not available
for linking. We can just the Windows variants that are always available.
Do the proper redirection in our custom unistd.h used with the Platform SDK.
_stricmp a Windows thing that is present in all the CRT, even in UCRT.
The stricmp() deprecated variant doesn't seem to exist elsewhere.
In some configuration it's not possible to link with stricmp() even though
_stricmp() is available.
These functions are not available when linking, so we should avoid using them.
Also mingw-w64 understands _CRT_NONSTDC_NO_DEPRECATE but not
_CRT_NONSTDC_NO_WARNINGS.
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).
The existence of search.h is not relevant for that. search.h may exist but does
not provide tfind, as on Windows.
If tfind.c is included for compilation, then the code needs to be built.
This is to allow clock_nanosleep to be used by emscripten
and potentially other platforms.
The file should not be compiled on windows platforms, as it won't
find sys/errno.h
mach/clock_types.h is needed for clock_id_t, and is only available on
macos.
Use prototype from tsearch(3), fixes the following warning when
targetin Android arm API 17.
../../src/misc/variables.c:154:32: warning: passing 'void **' to
parameter of type 'const void **' discards qualifiers in nested
pointer types [-Wincompatible-pointer-types-discards-qualifiers]
pp_var = tfind( &psz_name, &priv->var_root, varcmp );
^~~~~~~~~~~~~~~
aligned_alloc() is not portably suitable for over-alignments.
posix_memalign()/memalign() are still needed.
This essentially reverts commit 34cd965645.
Steve Lhomme
Thomas Guillem
Brad Smith
Rémi Denis-Courmont
Romain Vimont
Marvin Scholz
Mehdi Sabwat
Hugo Beauzée-Luyssen
Lyndon Brown
Alexandre Janniaux