This patch adds the GRND_INSECURE constant from Linux 5.6 to glibc's
sys/random.h. This is also added to the documentation. The constant
acts as a no-op for the Hurd implementation (as that doesn't check
whether the flags are known), which is semantically fine, while older
Linux kernels reject unknown flags with an EINVAL error.
Tested for x86_64.
All functions that have a format string, which can consume a long double
argument, must have one version for each long double format supported on
a platform. On powerpc64le, these functions currently have two versions
(i.e.: long double with the same format as double, and long double with
IBM Extended Precision format). Support for a third long double format
option (i.e. long double with IEEE long double format) is being prepared
and all the aforementioned functions now have a third version (not yet
exported on the master branch, but the code is in).
For these functions to get selected (during build time), references to
them in user programs (or dependent libraries) must get redirected to
the aforementioned new versions of the functions. This patch installs
the header magic required to perform such redirections.
Notice, however, that since the redirections only happen when
__LONG_DOUBLE_USES_FLOAT128 is set to 1, and no platform (including
powerpc64le) currently does it, no redirections actually happen.
Redirections and the exporting of the new functions will happen at the
same time (when powerpc64le adds ldbl-128ibm-compat to their Implies.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Reviewed-by: Paul E. Murphy <murphyp@linux.vnet.ibm.com>
The namespace pollution results in conform test failures if the tests
are run __USE_EXTERN_INLINES defined (e.g., when configuring with
CC="gcc -O3" CXX="g++ -O3").
Since commit a3cc4f48e9 ("Remove
--as-needed configure test."), --as-needed support is no longer
optional.
The macros are not much shorter and do not provide documentary
value, either, so this commit removes them.
Similarly to what has been done for printf-like functions, more
specifically to the internal implementation in __vfprintf_internal, this
patch extends __vstrfmon_l_internal to deal with long double values with
binary128 format (as a third format option and reusing the float128
implementation).
Tested for powerpc64le, powerpc64, x86_64, and with build-many-glibcs.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
As discussed previously on libc-alpha [1], this patch follows up the idea
and add both the __attribute_alloc_size__ on malloc functions (malloc,
calloc, realloc, reallocarray, valloc, pvalloc, and memalign) and limit
maximum requested allocation size to up PTRDIFF_MAX (taking into
consideration internal padding and alignment).
This aligns glibc with gcc expected size defined by default warning
-Walloc-size-larger-than value which warns for allocation larger than
PTRDIFF_MAX. It also aligns with gcc expectation regarding libc and
expected size, such as described in PR#67999 [2] and previously discussed
ISO C11 issues [3] on libc-alpha.
From the RFC thread [4] and previous discussion, it seems that consensus
is only to limit such requested size for malloc functions, not the system
allocation one (mmap, sbrk, etc.).
The implementation changes checked_request2size to check for both overflow
and maximum object size up to PTRDIFF_MAX. No additional checks are done
on sysmalloc, so it can still issue mmap with values larger than
PTRDIFF_T depending on the requested size.
The __attribute_alloc_size__ is for functions that return a pointer only,
which means it cannot be applied to posix_memalign (see remarks in GCC
PR#87683 [5]). The runtimes checks to limit maximum requested allocation
size does applies to posix_memalign.
Checked on x86_64-linux-gnu and i686-linux-gnu.
[1] https://sourceware.org/ml/libc-alpha/2018-11/msg00223.html
[2] https://gcc.gnu.org/bugzilla//show_bug.cgi?id=67999
[3] https://sourceware.org/ml/libc-alpha/2011-12/msg00066.html
[4] https://sourceware.org/ml/libc-alpha/2018-11/msg00224.html
[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
[BZ #23741]
* malloc/hooks.c (malloc_check, realloc_check): Use
__builtin_add_overflow on overflow check and adapt to
checked_request2size change.
* malloc/malloc.c (__libc_malloc, __libc_realloc, _mid_memalign,
__libc_pvalloc, __libc_calloc, _int_memalign): Limit maximum
allocation size to PTRDIFF_MAX.
(REQUEST_OUT_OF_RANGE): Remove macro.
(checked_request2size): Change to inline function and limit maximum
requested size to PTRDIFF_MAX.
(__libc_malloc, __libc_realloc, _int_malloc, _int_memalign): Limit
maximum allocation size to PTRDIFF_MAX.
(_mid_memalign): Use _int_memalign call for overflow check.
(__libc_pvalloc): Use __builtin_add_overflow on overflow check.
(__libc_calloc): Use __builtin_mul_overflow for overflow check and
limit maximum requested size to PTRDIFF_MAX.
* malloc/malloc.h (malloc, calloc, realloc, reallocarray, memalign,
valloc, pvalloc): Add __attribute_alloc_size__.
* stdlib/stdlib.h (malloc, realloc, reallocarray, valloc): Likewise.
* malloc/tst-malloc-too-large.c (do_test): Add check for allocation
larger than PTRDIFF_MAX.
* malloc/tst-memalign.c (do_test): Disable -Walloc-size-larger-than=
around tests of malloc with negative sizes.
* malloc/tst-posix_memalign.c (do_test): Likewise.
* malloc/tst-pvalloc.c (do_test): Likewise.
* malloc/tst-valloc.c (do_test): Likewise.
* malloc/tst-reallocarray.c (do_test): Replace call to reallocarray
with resulting size allocation larger than PTRDIFF_MAX with
reallocarray_nowarn.
(reallocarray_nowarn): New function.
* NEWS: Mention the malloc function semantic change.
This test would fail unnecessarily if the user running it had more than
64 groups since getgroups returns EINVAL if the size provided is less
than the number of supplementary group IDs. Instead dynamically
determine the number of supplementary groups the user has.
inttypes.h and stdint.h are in sysdeps/generic, but there are no other
versions of these headers anywhere in the source tree, so they aren’t
actually system-dependent. Move them to the subdirectory that
installs them (stdlib).
Reviewed-by: Joseph Myers <joseph@codesourcery.com>
* sysdeps/generic/inttypes.h, sysdeps/generic/stdint.h:
Move to stdlib.
* include/inttypes.h: Adjust to match.
* include/stdint.h: New wrapper.
When running the testsuite, building stdlib/isomac.c outputs the
following warning:
gcc -O -D_GNU_SOURCE -DIS_IN_build -include /home/aurel32/glibc-build/config.h isomac.c -o /home/aurel32/glibc-build/stdlib/isomac
isomac.c: In function ‘get_null_defines’:
isomac.c:260:3: warning: implicit declaration of function ‘close’; did you mean ‘pclose’? [-Wimplicit-function-declaration]
close (fd);
^~~~~
pclose
Fix that by adding the <unistd.h> include.
Changelog:
* stdlib/isomac.c: Include <unistd.h>.
This patch updates longlong.h from GCC. There were no local changes
in glibc (the previous version was identical to the r232143 GCC
version, apart from copyright dates which had been updated in both
places), so this patch makes it identical to the version in GCC again.
Tested for x86_64 and x86. Also tested with build-many-glibcs.py for
its RISC-V configurations, as the glibc architecture with the most
substantial changes in longlong.h in this patch.
* stdlib/longlong.h: Update from GCC.
There are a lot more printf variants than there are scanf variants,
and the code for setting up and tearing down their custom FILE
variants around the call to __vf(w)printf is more complicated and
variable. Therefore, I have added _internal versions of all the
v*printf variants, rather than introducing helper routines so that
they can all directly call __vf(w)printf_internal, as was done with
scanf.
As with the scanf changes, in this patch the _internal functions still
look at the environmental mode bits and all callers pass 0 for the
flags parameter.
Several of the affected public functions had _IO_ name aliases that
were not exported (but, in one case, appeared in libio.h anyway);
I was originally planning to leave them as aliases to avoid having
to touch internal callers, but it turns out ldbl_*_alias only work
for exported symbols, so they've all been removed instead. It also
turns out there were hardly any internal callers. _IO_vsprintf and
_IO_vfprintf *are* exported, so those two stick around.
Summary for the changes to each of the affected symbols:
_IO_vfprintf, _IO_vsprintf:
All internal calls removed, thus the internal declarations, as well
as uses of libc_hidden_proto and libc_hidden_def, were also removed.
The external symbol is now exposed via uses of ldbl_strong_alias
to __vfprintf_internal and __vsprintf_internal, respectively.
_IO_vasprintf, _IO_vdprintf, _IO_vsnprintf,
_IO_vfwprintf, _IO_vswprintf,
_IO_obstack_vprintf, _IO_obstack_printf:
All internal calls removed, thus declaration in internal headers
were also removed. They were never exported, so there are no
aliases tying them to the internal functions. I.e.: entirely gone.
__vsnprintf:
Internal calls were always preceded by macros such as
#define __vsnprintf _IO_vsnprintf, and
#define __vsnprintf vsnprintf
The macros were removed and their uses replaced with calls to the
new internal function __vsnprintf_internal. Since there were no
internal calls, the internal declaration was also removed. The
external symbol is preserved with ldbl_weak_alias to ___vsnprintf.
__vfwprintf:
All internal calls converted into calls to __vfwprintf_internal,
thus the internal declaration was removed. The function is now a
wrapper that calls __vfwprintf_internal. The external symbol is
preserved.
__vswprintf:
Similarly, but no external symbol.
__vasprintf, __vdprintf, __vfprintf, __vsprintf:
New internal wrappers. Not exported.
vasprintf, vdprintf, vfprintf, vsprintf, vsnprintf,
vfwprintf, vswprintf,
obstack_vprintf, obstack_printf:
These functions used to be aliases to the respective _IO_* function,
they are now aliases to their respective __* functions.
Tested for powerpc and powerpc64le.
On platforms where long double used to have the same format as double,
but later switched to a different format (alpha, s390, sparc, and
powerpc), accessing the older behavior is possible and it happens via
__nldbl_* functions (not on the API, but accessible from header
redirection and from compat symbols). These functions write to the
global flag __ldbl_is_dbl, which tells other functions that long double
variables should be handled as double. This patch takes the first step
towards removing this global flag and creates __vstrfmon_l_internal,
which takes an explicit flags parameter.
This change arguably makes the generated code slightly worse on
architectures where __ldbl_is_dbl is never true; right now, on those
architectures, it's a compile-time constant; after this change, the
compiler could theoretically prove that __vstrfmon_l_internal was
never called with a nonzero flags argument, but it would probably need
LTO to do it. This is not performance critical code and I tend to
think that the maintainability benefits of removing action at a
distance are worth it. However, we _could_ wrap the runtime flag
check with a macro that was defined to ignore its argument and always
return false on architectures where __ldbl_is_dbl is never true, if
people think the codegen benefits are important.
Tested for powerpc and powerpc64le.
On systems without enough random-access memory, stdlib/test-bz22786
will go deeply into swap and time out, even with a substantial
TIMEOUTFACTOR. This commit adds a facility to construct repeating
strings with alias mappings, so that the requirement for physical
memory, and uses it in stdlib/test-bz22786.
glibc support for 64-bit time_t on 32-bit architectures
will involve:
- Using 64-bit times inside glibc, with conversions
to and from 32-bit times taking place as necessary
for interfaces using such times.
- Adding 64-bit-time support in the glibc public API.
This support should be dynamic, i.e. glibc should
provide both 32-bit and 64-bit implementations and
let user code choose at compile time whether to use
the 32-bit or 64-bit interfaces.
This requires a glibc-internal name for a type for times
that are always 64-bit.
Based on __TIMESIZE, a new macro is defined, __TIME64_T_TYPE,
which is always the right __*_T_TYPE to hold a 64-bit-time.
__TIME64_T_TYPE equals __TIME_T_TYPE if __TIMESIZE equals 64
and equals __SQUAD_T_TYPE otherwise.
__time64_t can then replace uses of internal_time_t.
This patch was tested by running 'make check' on branch
master then applying this patch and its predecessor and
running 'make check' again, and checking that both 'make
check' yield identical results. This was done on
x86_64-linux-gnu and i686-linux-gnu.
* bits/time64.h: New file.
* include/time.h: Replace internal_time_t with __time64_t.
* posix/bits/types (__time64_t): Add.
* stdlib/Makefile: Add bits/time64.h to includes.
* time/tzfile.c: Replace internal_time_t with __time64_t.
To determine whether the default time_t interfaces are 32-bit
and so need conversions, or are 64-bit and so are compatible
with the internal 64-bit type without conversions, a macro
giving the size of the default time_t is also required.
This macro is called __TIMESIZE.
This macro can then be used instead of __WORDSIZE in msq-pad.h
and shm-pad.h files, which in turn allows removing their x86
variants, and in sem-pad.h files but keeping the x86 variant.
This patch was tested by running 'make check' on branch master
then applying this patch and running 'make check' again, and
checking that both 'make check' yield identical results.
This was done on x86_64-linux-gnu and i686-linux-gnu.
* bits/timesize.h: New file.
* stdlib/Makefile (headers): Add bits/timesize.h.
* sysdeps/unix/sysv/linux/bits/msq-pad.h
(__MSQ_PAD_AFTER_TIME): Use __TIMESIZE instead of __WORDSIZE.
* sysdeps/unix/sysv/linux/bits/sem-pad.h
(__SEM_PAD_AFTER_TIME): Likewise.
* sysdeps/unix/sysv/linux/bits/shm-pad.h
(__SHM_PAD_AFTER_TIME): Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/msq-pad.h
(__MSQ_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/sem-pad.h
(__SEM_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/hppa/bits/shm-pad.h
(__SHM_PAD_BEFORE_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Likewise.
* sysdeps/unix/sysv/linux/mips/bits/msq-pad.h
(__MSQ_PAD_AFTER_TIME, __MSQ_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/msq-pad.h
(__MSQ_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/sem-pad.h
(__SEM_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/powerpc/bits/shm-pad.h
(__SHM_PAD_BEFORE_TIME, __SHM_PAD_BETWEEN_TIME_AND_SEGSZ): Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/msq-pad.h
(__MSQ_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/sem-pad.h
(__SEM_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/sparc/bits/shm-pad.h
(__SHM_PAD_BEFORE_TIME): Likewise.
* sysdeps/unix/sysv/linux/x86/bits/msq-pad.h: Delete file.
* sysdeps/unix/sysv/linux/x86/bits/shm-pad.h: Likewise.
* sysdeps/unix/sysv/linux/x86/bits/timesize.h: New file.
The function f1a, executed on a stack of size 32k, allocates an object of
size 32k on the stack. Make the stack variables static to reduce
excessive stack usage.
If the compiler reduces the stack usage in function f1 before calling
into function f2, then when we swapcontext back to f1 and continue
execution we may overwrite registers that were spilled to the stack
while f2 was executing. Later when we return to f2 the corrupt
registers will be reloaded from the stack and the test will crash. This
was most commonly observed on i686 with __x86.get_pc_thunk.dx and
needing to save and restore $edx. Overall i686 has few registers and
the spilling to the stack is bound to happen, therefore the solution to
making this test robust is to split function f1 into two parts f1a and
f1b, and allocate f1b it's own stack such that subsequent execution does
not overwrite the stack in use by function f2.
Tested on i686 and x86_64.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Initially, this function was restricted to _GNU_SOURCE, but experience
shows that compatibility with existing build systems is improved if we
declare it under _DEFAULT_SOURCE as well.
The test tries to allocate more than 2^31 bytes which will always fail on s390
as it has maximum 2^31bit of memory.
Before commit 6c3a8a9d86, this test returned
unsupported if malloc fails. This patch re enables this behaviour.
Furthermore support_delete_temp_files() failed to remove the temp directory
in this case as it is not empty due to the created symlink.
Thus the creation of the symlink is moved behind malloc.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
ChangeLog:
* stdlib/test-bz22786.c (do_test): Return EXIT_UNSUPPORTED
if malloc fails.
__fentry__ symbol is currently not defined for other architectures.
Attempts to introduce it cause abicheck to fail, because it will be
available since 2.29 earliest, and not 2.13, which is the case for
Intel. With the new code, abicheck passes for i686-linux-gnu,
x86_64-linux-gnu and x86_64-linux-gnu32 triples.
ChangeLog:
* stdlib/Versions: Remove __fentry__.
* sysdeps/i386/Versions: Add __fentry__.
* sysdeps/x86_64/Versions: Add __fentry__.
Add <bits/indirect-return.h> and include it in <ucontext.h>.
__INDIRECT_RETURN defined in <bits/indirect-return.h> indicates if
swapcontext requires special compiler treatment. The default
__INDIRECT_RETURN is empty.
On x86, when shadow stack is enabled, __INDIRECT_RETURN is defined
with indirect_return attribute, which has been added to GCC 9, to
indicate that swapcontext returns via indirect branch. Otherwise
__INDIRECT_RETURN is defined with returns_twice attribute.
When shadow stack is enabled, remove always_inline attribute from
prepare_test_buffer in string/tst-xbzero-opt.c to avoid:
tst-xbzero-opt.c: In function ‘prepare_test_buffer’:
tst-xbzero-opt.c:105:1: error: function ‘prepare_test_buffer’ can never be inlined because it uses setjmp
prepare_test_buffer (unsigned char *buf)
when indirect_return attribute isn't available.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* bits/indirect-return.h: New file.
* misc/sys/cdefs.h (__glibc_has_attribute): New.
* sysdeps/x86/bits/indirect-return.h: Likewise.
* stdlib/Makefile (headers): Add bits/indirect-return.h.
* stdlib/ucontext.h: Include <bits/indirect-return.h>.
(swapcontext): Add __INDIRECT_RETURN.
* string/tst-xbzero-opt.c (ALWAYS_INLINE): New.
(prepare_test_buffer): Use it.
Various glibc testcases use tmpnam in ways subject to race conditions
(generate a temporary file name, then later open that file without
O_EXCL).
This patch fixes those tests to use mkstemp - generally a minimal
local fix to use mkstemp instead of tmpnam, rather than a larger fix
to use other testsuite infrastructure for temporary files. The
unchanged use of tmpnam in posix/wordexp-test.c would fail safe in the
event of a race (it's generating a name for use with mkdir rather than
for a file to be opened for writing).
Tested for x86_64.
* grp/tst_fgetgrent.c: Include <unistd.h>.
(main): Use mkstemp instead of tmpnam.
* io/test-utime.c (main): Likewise.
* posix/annexc.c (macrofile): Change to modifiable array.
(get_null_defines): Use mkstemp instead of tmpnam. Do not remove
macrofile here.
* posix/bug-getopt1.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt2.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt3.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt4.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* posix/bug-getopt5.c: Include <stdlib.h>.
(do_test): Use mkstemp instead of tmpnam.
* stdio-common/bug7.c: Include <stdlib.h> and <unistd.h>.
(main): Use mkstemp instead of tmpnam.
* stdio-common/tst-fdopen.c: Include <stdlib.h>.
(main): Use mkstemp instead of tmpnam.
* stdio-common/tst-ungetc.c: Include <stdlib.h>.
(main): use mkstemp instead of tmpnam.
* stdlib/isomac.c (macrofile): Change to modifiable array.
(get_null_defines): Use mkstemp instead of tmpnam. Do not remove
macrofile here.
The functions encrypt, setkey, encrypt_r, setkey_r, cbc_crypt,
ecb_crypt, and des_setparity should not be used in new programs,
because they use the DES block cipher, which is unacceptably weak by
modern standards. Demote all of them to compatibility symbols, and
remove their prototypes from installed headers. cbc_crypt, ecb_crypt,
and des_setparity were already compat symbols when glibc was
configured with --disable-obsolete-rpc.
POSIX requires encrypt and setkey to be available when _XOPEN_CRYPT
is defined, so this change also removes the definition of X_OPEN_CRYPT
from <unistd.h>.
The entire "DES Encryption" section is dropped from the manual, as is
the mention of AUTH_DES and FIPS 140-2 in the introduction to
crypt.texi. The documentation of 'memfrob' cross-referenced the DES
Encryption section, which is replaced by a hyperlink to libgcrypt, and
while I was in there I spruced up the actual documentation of
'memfrob' and 'strfry' a little. It's still fairly jokey, because
those functions _are_ jokes, but they do also have real use cases, so
people trying to use them for real should have all the information
they need.
DES-based authentication for Sun RPC is also insecure and should be
deprecated or even removed, but maybe that can be left as TI-RPC's
problem.
This patch adds tests for bug 23007, strtod ignoring any sign in the
input string in the case of a NaN result.
Tested for x86_64.
[BZ #23007]
* stdlib/tst-strtod-nan-sign-main.c: New file.
* stdlib/tst-strtod-nan-sign.c: Likewise.
* wcsmbs/tst-wcstod-nan-sign.c: Likewise.
* stdlib/Makefile (tests): Add tst-strtod-nan-sign.
($(objpfx)tst-strtod-nan-sign): Depend on $(libm).
* wcsmbs/Makefile (tests) Add tst-wcstod-nan-sign.
($(objpfx)tst-wcstod-nan-sign): Depend on $(libm).
As reported in bug 23007, strtod ignores any sign in the input string
in the case of a NaN result. Thes patch fixes this.
Tested for x86_64 (in conjunction with tests to be added separately).
[BZ #23007]
* stdlib/strtod_l.c (____STRTOF_INTERNAL): Return NaN of
appropriate sign.
As shown by bug 23279, strtod's round_and_return has an off-by-one
error in its overflow detection, only counting an exponent greater
than MAX_EXP as overflowing when an exponent of MAX_EXP also means
overflow (recall the ISO C definition of DBL_MAX_EXP etc. is based on
a floating-point model where 2^exp is multiplied by a value in the
interval [0.5, 1), so 2^MAX_EXP is not representable).
For decimal arguments to strtod, a separate overflow check in the main
implementation covers the case where the integer part of the argument
(truncated to the nearest integer towards zero) has more than MAX_EXP
bits, meaning that this issue in round_and_return only affects cases
(arguments with absolute value strictly between the maximum
representable value and 2^MAX_EXP) where overflow depends on the
rounding mode; in such cases, the returned value would still have been
correct on overflow but without the overflow exception being raised or
errno being set to ERANGE. For hex float arguments, however, other
cases can arise, as shown in bug 23279, where a value with exponent
already set to MAX_EXP is passed into round_and_return and a result
can wrongly end up being NaN, or infinity instead of the largest
finite value.
This patch fixes the off-by-one error, adds testing of overflow
exceptions to the tst-strtod-round framework, and adds tests of these
issues.
Tested for x86_64. Also ran the tst-strtod-round tests for powerpc to
make sure the new tests didn't introduce any new failures for IBM long
double.
[BZ #23279]
* stdlib/strtod_l.c (round_and_return): Handle an exponent of
MAX_EXP as overflowing.
* stdlib/gen-tst-strtod-round.c (string_to_fp): Clear MPFR
overflow flag.
(round_str): Output also whether result overflows in each rounding
mode.
* stdlib/tst-strtod-round-data: Add more tests.
* stdlib/tst-strtod-round-data.h: Regenerated.
* stdlib/tst-strtod-round-skeleton.c (_XNTRY): Update comment.
(TEST): Handle extra arguments for overflow flags.
(struct test_overflow): New type.
[!FE_OVERFLOW] (FE_OVERFLOW): Define to 0.
(GEN_ONE_TEST): Clear all exceptions. Test overflow flag.
(test_in_one_mode): Take argument with overflow information.
(do_test): Update calls to test_in_one_mode.
