Parametrize test-strstr.c so it can be used to check wcsstr.
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
Reviewed-by: DJ Delorie <dj@redhat.com>
Complete the internal renaming from "C2X" and related names in GCC by
renaming *-c2x and *-gnu2x tests to *-c23 and *-gnu23.
Tested for x86_64, and with build-many-glibcs.py for powerpc64le.
WG14 decided to use the name C23 as the informal name of the next
revision of the C standard (notwithstanding the publication date in
2024). Update references to C2X in glibc to use the C23 name.
This is intended to update everything *except* where it involves
renaming files (the changes involving renaming tests are intended to
be done separately). In the case of the _ISOC2X_SOURCE feature test
macro - the only user-visible interface involved - support for that
macro is kept for backwards compatibility, while adding
_ISOC23_SOURCE.
Tested for x86_64.
This patch implements comprehensive tests for strlcat/wcslcat
functions. Tests are mostly derived from strncat test suites
and modified to incorporate strlcat/wcslcat specifications.
Reviewed-by: DJ Delorie <dj@redhat.com>
This patch implements comprehensive tests for strlcpy/wcslcpy
functions. Tests are mostly derived from strncpy test suites
and modified to incorporate strlcpy/wcslcpy specifications.
Reviewed-by: DJ Delorie <dj@redhat.com>
ISO C2x defines scanf length modifiers wN (for intN_t / int_leastN_t /
uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t).
Add support for those length modifiers, similar to the printf support
previously added.
Tested for x86_64 and x86.
Some locales define a list of mapping pairs of alternate digits and
separators for input digits (to_inpunct). This require the scanf
to create a list of all possible inputs for the optional type
modifier 'I'.
Checked on x86_64-linux-gnu.
Reviewed-by: Joe Simmons-Talbott <josimmon@redhat.com>
Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to
be excluded from the fortification.
On top of that:
- some tests explicitly verify that some level of fortification works
appropriately, we therefore shouldn't modify the level set for them.
- some objects need to be build with optimization disabled, which
prevents _FORTIFY_SOURCE to be used for them.
Assembler files that implement architecture specific versions of the
fortified routines were not excluded from _FORTIFY_SOURCE as there is no
C header included that would impact their behavior.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
ISO C2x defines printf length modifiers wN (for intN_t / int_leastN_t
/ uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t).
Add support for those length modifiers (such a feature was previously
requested in bug 24466). scanf support is to be added separately.
GCC 13 has format checking support for these modifiers.
When used with the support for registering format specifiers, these
modifiers are translated to existing flags in struct printf_info,
rather than trying to add some way of distinguishing them without
breaking the printf_info ABI. C2x requires an error to be returned
for unsupported values of N; this is implemented for printf-family
functions, but the parse_printf_format interface doesn't support error
returns, so such an error gets discarded by that function.
Tested for x86_64 and x86.
Reflow Makefile.
Sort using updated scripts/sort-makefile-lines.py.
Code generation is changed as routines are linked in sorted order
as expected.
No regressions on x86_64 and i686.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reflow Makefile.
Sort using scripts/sort-makefile-lines.py.
No code generation changes observed in binary artifacts.
No regressions on x86_64 and i686.
C2x adds binary integer constants starting with 0b or 0B, and supports
those constants for the %i scanf format (in addition to the %b format,
which isn't yet implemented for scanf in glibc). Implement that scanf
support for glibc.
As with the strtol support, this is incompatible with previous C
standard versions, in that such an input string starting with 0b or 0B
was previously required to be parsed as 0 (with the rest of the input
potentially matching subsequent parts of the scanf format string).
Thus this patch adds 12 new __isoc23_* functions per long double
format (12, 24 or 36 depending on how many long double formats the
glibc configuration supports), with appropriate header redirection
support (generally very closely following that for the __isoc99_*
scanf functions - note that __GLIBC_USE (DEPRECATED_SCANF) takes
precedence over __GLIBC_USE (C2X_STRTOL), so the case of GNU
extensions to C89 continues to get old-style GNU %a and does not get
this new feature). The function names would remain as __isoc23_* even
if C2x ends up published in 2024 rather than 2023.
When scanf %b support is added, I think it will be appropriate for all
versions of scanf to follow C2x rules for inputs to the %b format
(given that there are no compatibility concerns for a new format).
Tested for x86_64 (full glibc testsuite). The first version was also
tested for powerpc (32-bit) and powerpc64le (stdio-common/ and wcsmbs/
tests), and with build-many-glibcs.py.
C2x adds binary integer constants starting with 0b or 0B, and supports
those constants in strtol-family functions when the base passed is 0
or 2. Implement that strtol support for glibc.
As discussed at
<https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>,
this is incompatible with previous C standard versions, in that such
an input string starting with 0b or 0B was previously required to be
parsed as 0 (with the rest of the string unprocessed). Thus, as
proposed there, this patch adds 20 new __isoc23_* functions with
appropriate header redirection support. This patch does *not* do
anything about scanf %i (which will need 12 new functions per long
double variant, so 12, 24 or 36 depending on the glibc configuration),
instead leaving that for a future patch. The function names would
remain as __isoc23_* even if C2x ends up published in 2024 rather than
2023.
Making this change leads to the question of what should happen to
internal uses of these functions in glibc and its tests. The header
redirection (which applies for _GNU_SOURCE or any other feature test
macros enabling C2x features) has the effect of redirecting internal
uses but without those uses then ending up at a hidden alias (see the
comment in include/stdio.h about interaction with libc_hidden_proto).
It seems desirable for the default for internal uses to be the same
versions used by normal code using _GNU_SOURCE, so rather than doing
anything to disable that redirection, similar macro definitions to
those in include/stdio.h are added to the include/ headers for the new
functions.
Given that the default for uses in glibc is for the redirections to
apply, the next question is whether the C2x semantics are correct for
all those uses. Uses with the base fixed to 10, 16 or any other value
other than 0 or 2 can be ignored. I think this leaves the following
internal uses to consider (an important consideration for review of
this patch will be both whether this list is complete and whether my
conclusions on all entries in it are correct):
benchtests/bench-malloc-simple.c
benchtests/bench-string.h
elf/sotruss-lib.c
math/libm-test-support.c
nptl/perf.c
nscd/nscd_conf.c
nss/nss_files/files-parse.c
posix/tst-fnmatch.c
posix/wordexp.c
resolv/inet_addr.c
rt/tst-mqueue7.c
soft-fp/testit.c
stdlib/fmtmsg.c
support/support_test_main.c
support/test-container.c
sysdeps/pthread/tst-mutex10.c
I think all of these places are OK with the new semantics, except for
resolv/inet_addr.c, where the POSIX semantics of inet_addr do not
allow for binary constants; thus, I changed that file (to use
__strtoul_internal, whose semantics are unchanged) and added a test
for this case. In the case of posix/wordexp.c I think accepting
binary constants is OK since POSIX explicitly allows additional forms
of shell arithmetic expressions, and in stdlib/fmtmsg.c SEV_LEVEL is
not in POSIX so again I think accepting binary constants is OK.
Functions such as __strtol_internal, which are only exported for
compatibility with old binaries from when those were used in inline
functions in headers, have unchanged semantics; the __*_l_internal
versions (purely internal to libc and not exported) have a new
argument to specify whether to accept binary constants.
As well as for the standard functions, the header redirection also
applies to the *_l versions (GNU extensions), and to legacy functions
such as strtoq, to avoid confusing inconsistency (the *q functions
redirect to __isoc23_*ll rather than needing their own __isoc23_*
entry points). For the functions that are only declared with
_GNU_SOURCE, this means the old versions are no longer available for
normal user programs at all. An internal __GLIBC_USE_C2X_STRTOL macro
is used to control the redirections in the headers, and cases in glibc
that wish to avoid the redirections - the function implementations
themselves and the tests of the old versions of the GNU functions -
then undefine and redefine that macro to allow the old versions to be
accessed. (There would of course be greater complexity should we wish
to make any of the old versions into compat symbols / avoid them being
defined at all for new glibc ABIs.)
strtol_l.c has some similarity to strtol.c in gnulib, but has already
diverged some way (and isn't listed at all at
https://sourceware.org/glibc/wiki/SharedSourceFiles unlike strtoll.c
and strtoul.c); I haven't made any attempts at gnulib compatibility in
the changes to that file.
I note incidentally that inttypes.h and wchar.h are missing the
__nonnull present on declarations of this family of functions in
stdlib.h; I didn't make any changes in that regard for the new
declarations added.
clang emits an warning when a double alias redirection is used, to warn
the the original symbol will be used even when weak definition is
overridden. However, this is a common pattern for weak_alias, where
multiple alias are set to same symbol.
Reviewed-by: Fangrui Song <maskray@google.com>
Similar to d0fa09a770, but for wchar.h. Fixes [BZ #27087] by applying
all long double related asm redirections before using functions in
bits/wchar2.h.
Moves the function declarations from wcsmbs/bits/wchar2.h to a new file
wcsmbs/bits/wchar2-decl.h that will be included first in wcsmbs/wchar.h.
Tested with build-many-glibcs.py.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Make test-c8rtomb.out and test-mbrtoc8.out depend on $(gen-locales) for
xsetlocale (LC_ALL, "de_DE.UTF-8");
xsetlocale (LC_ALL, "zh_HK.BIG5-HKSCS");
Reviewed-by: Sunil K Pandey <skpgkp2@gmail.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
This change adds tests for the mbrtoc8 and c8rtomb functions adopted for
C++20 via WG21 P0482R6 and for C2X via WG14 N2653, and for the char8_t
typedef adopted for C2X from WG14 N2653.
The tests for mbrtoc8 and c8rtomb specifically exercise conversion to
and from Big5-HKSCS because of special cases that arise with that encoding.
Big5-HKSCS defines some double byte sequences that convert to more than
one Unicode code point. In order to test this, the locale dependencies
for running tests under wcsmbs is expanded to include zh_HK.BIG5-HKSCS.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This change provides implementations for the mbrtoc8 and c8rtomb
functions adopted for C++20 via WG21 P0482R6 and for C2X via WG14
N2653. It also provides the char8_t typedef from WG14 N2653.
The mbrtoc8 and c8rtomb functions are declared in uchar.h in C2X
mode or when the _GNU_SOURCE macro or C++20 __cpp_char8_t feature
test macro is defined.
The char8_t typedef is declared in uchar.h in C2X mode or when the
_GNU_SOURCE macro is defined and the C++20 __cpp_char8_t feature
test macro is not defined (if __cpp_char8_t is defined, then char8_t
is a builtin type).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 7061 files FOO.
I then removed trailing white space from math/tgmath.h,
support/tst-support-open-dev-null-range.c, and
sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following
obscure pre-commit check failure diagnostics from Savannah. I don't
know why I run into these diagnostics whereas others evidently do not.
remote: *** 912-#endif
remote: *** 913:
remote: *** 914-
remote: *** error: lines with trailing whitespace found
...
remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
C2X adds a printf %b format (see
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2630.pdf>, accepted
for C2X), for outputting integers in binary. It also has recommended
practice for a corresponding %B format (like %b, but %#B starts the
output with 0B instead of 0b). Add support for these formats to
glibc.
One existing test uses %b as an example of an unknown format, to test
how glibc printf handles unknown formats; change that to %v. Use of
%b and %B as user-registered format specifiers continues to work (and
we already have a test that covers that, tst-printfsz.c).
Note that C2X also has scanf %b support, plus support for binary
constants starting 0b in strtol (base 0 and 2) and scanf %i (strtol
base 0 and scanf %i coming from a previous paper that added binary
integer literals). I intend to implement those features in a separate
patch or patches; as discussed in the thread starting at
<https://sourceware.org/pipermail/libc-alpha/2020-December/120414.html>,
they will be more complicated because they involve adding extra public
symbols to ensure compatibility with existing code that might not
expect 0b constants to be handled by strtol base 0 and 2 and scanf %i,
whereas simply adding a new format specifier poses no such
compatibility concerns.
Note that the actual conversion from integer to string uses existing
code in _itoa.c. That code has special cases for bases 8, 10 and 16,
probably so that the compiler can optimize division by an integer
constant in the code for those bases. If desired such special cases
could easily be added for base 2 as well, but that would be an
optimization, not actually needed for these printf formats to work.
Tested for x86_64 and x86. Also tested with build-many-glibcs.py for
aarch64-linux-gnu with GCC mainline to make sure that the test does
indeed build with GCC 12 (where format checking warnings are enabled
for most of the test).
I used these shell commands:
../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright
(cd ../glibc && git commit -am"[this commit message]")
and then ignored the output, which consisted lines saying "FOO: warning:
copyright statement not found" for each of 6694 files FOO.
I then removed trailing white space from benchtests/bench-pthread-locks.c
and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this
diagnostic from Savannah:
remote: *** pre-commit check failed ...
remote: *** error: lines with trailing whitespace found
remote: error: hook declined to update refs/heads/master
The function mbstowcs, by an XSI extension to POSIX, accepts a null
pointer for the destination wchar_t array. This API behaviour allows
you to use the function to compute the length of the required wchar_t
array i.e. does the conversion without storing it and returns the
number of wide characters required.
We remove the __write_only__ markup for the first argument because it
is not true since the destination may be a null pointer, and so the
length argument may not apply. We remove the markup otherwise the new
test case cannot be compiled with -Werror=nonnull.
We add a new test case for mbstowcs which exercises the destination is
a null pointer behaviour which we have now explicitly documented.
The mbsrtowcs and mbsnrtowcs behave similarly, and mbsrtowcs is
documented as doing this in C11, even if the standard doesn't come out
and call out this specific use case. We add one note to each of
mbsrtowcs and mbsnrtowcs to call out that they support a null pointer
for the destination.
The wcsrtombs function behaves similarly but in the other way around
and allows you to use a null destination pointer to compute how many
bytes you would need to convert the wide character input. We document
this particular case also, but leave wcsnrtombs as a references to
wcsrtombs, so the reader must still read the details of the semantics
for wcsrtombs.
glibc does:
/* There should be no difference between the UTF-32 handling required
by c32rtomb and the wchar_t handling which has long since been
implemented in wcrtomb. */
weak_alias (__wcrtomb, c32rtomb)
/* There should be no difference between the UTF-32 handling required
by mbrtoc32 and the wchar_t handling which has long since been
implemented in mbrtowc. */
weak_alias (__mbrtowc, mbrtoc32)
The reasoning in those comments to justify those aliases is incorrect:
ISO C requires that, for the case of a NULL mbstate_t* being passed,
each function has its *own* internal static mbstate_t. Thus a program
must be able to use both wcrtomb and c32rtomb at the same time with
each keeping its own separate state, and likewise for mbrtowc and
mbrtoc32.
This patch duly sets up separarate char32_t function that wrap the
wchar_t ones. Note that the included test only covers the mbrtoc32 /
mbrtowc pair. While I think the change made is logically correct for
c32rtomb / wcrtomb as well, I'm not sure we have a locale with a
suitable state-dependent multibyte encoding for testing that part of
the change.
Tested for x86_64.
[BZ #23793]
* wcsmbs/c32rtomb.c: New file.
* wcsmbs/mbrtoc32.c: Likewise.
* wcsmbs/tst-c32-state.c: Likewise.
* wcsmbs/mbrtowc.c (mbrtoc32): Do not define as alias.
* wcsmbs/wcrtomb.c (c32rtomb): Likewise.
* wcsmbs/Makefile (routines): Add mbrtoc32 and c32rtomb.
(tests): Add tst-c32-state.
[$(run-built-tests) = yes] ($(objpfx)tst-c32-state.out): Depend on
$(gen-locales).
The c16rtomb implementation has:
// XXX The ISO C 11 spec I have does not say anything about handling
// XXX surrogates in this interface.
The DR#488 resolution, as applied to C2X, requires surrogate pairs to
be handled here (so the first call returns 0 and stores the high
surrogate in the mbstate_t, while the second call combines the
surrogates, produces a multibyte character and returns the number of
bytes written). This patch implements that. (mbrtoc16 already
handled producing surrogates as output.)
Tested for x86_64.
[BZ #23794]
* wcsmbs/c16rtomb.c (c16rtomb): Save first character of surrogate
pair and return 0 in that case, and use saved character to
interpret following character.
* wcsmbs/tst-c16-surrogate.c: New file.
* wcsmbs/Makefile (tests): Add tst-c16-surrogate.c.
[$(run-built-tests) = yes] ($(objpfx)tst-c16-surrogate.out):
Depend on $(gen-locales)
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).
C99 specifies that the EOF condition on a file is "sticky": once EOF
has been encountered, all subsequent reads should continue to return
EOF until the file is closed or something clears the "end-of-file
indicator" (e.g. fseek, clearerr). This is arguably a change from
C89, where the wording was ambiguous; the BSDs always had sticky EOF,
but the System V lineage would attempt to read from the underlying fd
again. GNU libc has followed System V for as long as we've been
using libio, but nowadays C99 conformance and BSD compatibility are
more important than System V compatibility.
You might wonder if changing the _underflow impls is sufficient to
apply the C99 semantics to all of the many stdio functions that
perform input. It should be enough to cover all paths to _IO_SYSREAD,
and the only other functions that call _IO_SYSREAD are the _seekoff
impls, which is OK because seeking clears EOF, and the _xsgetn impls,
which, as far as I can tell, are unused within glibc.
The test programs in this patch use a pseudoterminal to set up the
necessary conditions. To facilitate this I added a new test-support
function that sets up a pair of pty file descriptors for you; it's
almost the same as BSD openpty, the only differences are that it
allocates the optionally-returned tty pathname with malloc, and that
it crashes if anything goes wrong.
[BZ #1190]
[BZ #19476]
* libio/fileops.c (_IO_new_file_underflow): Return EOF immediately
if the _IO_EOF_SEEN bit is already set; update commentary.
* libio/oldfileops.c (_IO_old_file_underflow): Likewise.
* libio/wfileops.c (_IO_wfile_underflow): Likewise.
* support/support_openpty.c, support/tty.h: New files.
* support/Makefile (libsupport-routines): Add support_openpty.
* libio/tst-fgetc-after-eof.c, wcsmbs/test-fgetwc-after-eof.c:
New test cases.
* libio/Makefile (tests): Add tst-fgetc-after-eof.
* wcsmbs/Makefile (tests): Add tst-fgetwc-after-eof.
As noted in bug 17979 (and as I noted earlier in
<https://sourceware.org/ml/libc-alpha/2012-02/msg00647.html>), uchar.h
has gratuitously complicated code to determine the types for char16_t
and char32_t, and to reject including that header for pre-C11
compilers not defining __CHAR16_TYPE__ and __CHAR32_TYPE__. Since
those types are always required to match uint_least16_t and
uint_least32_t, which glibc knows how to define without reference to
such predefined macros, it's safe just to define those types the same
as the *least* types are defined in stdint.h, so allowing the header
to work with (for example) GCC 4.3.
This patch implements that. bits/types.h is made to define
__int_leastN_t and __uint_leastN_t so the logic for those types can
stay in a single place, and stdint.h is made to use those __*_t to
define the public *_t types. uchar.h is then made to use
__uint_least16_t and __uint_least32_t to define char16_t and char32_t,
so simplifying the logic there. A new test is added that verifies the
types chosen for char16_t and char32_t do indeed match the types the
compiler uses for u"" and U"" string literals.
Tested for x86_64. (I have not tested with any of the older compilers
for which this would actually make a difference to whether you can
include uchar.h.)
[BZ #17979]
* posix/bits/types.h (__int_least8_t): New typedef.
(__uint_least8_t): Likewise.
(__int_least16_t): Likewise.
(__uint_least16_t): Likewise.
(__int_least32_t): Likewise.
(__uint_least32_t): Likewise.
(__int_least64_t): Likewise.
(__uint_least64_t): Likewise.
* sysdeps/generic/stdint.h (int_least8_t): Define using
__int_least8_t.
(int_least16_t): Define using __int_least16_t.
(int_least32_t): Define using __int_least32_t.
(int_least64_t): Define using __int_least64_t.
(uint_least8_t): Define using __uint_least8_t.
(uint_least16_t): Define using __uint_least16_t.
(uint_least32_t): Define using __uint_least32_t.
(uint_least64_t): Define using __uint_least64_t.
* wcsmbs/uchar.h: Include <bits/types.h>.
(char16_t): Define using __uint_least16_t conditional only on
[!__USE_ISOCXX11].
(char32_t): Define using __uint_least32_t conditional only on
[!__USE_ISOCXX11].
* wcsmbs/test-char-types.c: New file.
* wcsmbs/Makefile (tests): Add test-char-types.
The implementations are contained with sysdeps/ieee754/float128 as
they are only built when _Float128 is enabled within libc/m.
* include/gmp.h (__mpn_construct_float128): New declaration.
* include/stdlib.h: Include bits/floatn.h for _Float128 tests.
(__strtof128_l): New declaration.
(__strtof128_nan): Likewise.
(__wcstof128_nan): Likewise.
(__strtof128_internal): Likewise.
(____strtof128_l_internal): Likewise.
* include/wchar.h: Include bits/floatn.h for _Float128 tests.
(__wcstof128_l): New declaration.
(__wcstof128_internal): Likewise.
* stdlib/Makefile (bug-strtod2): Link libm too.
* stdlib/stdlib.h (strtof128): New declaration.
(strtof128_l): Likewise.
* stdlib/tst-strtod-nan-locale-main.c: Updated to use
tst-strtod.h macros to ensure float128 gets tested too.
* stdlib/tst-strtod-round-skeleton.c (CHOOSE_f128): New macro.
* stdlib/tst-strtod.h: Include bits/floatn.h for _Float128
tests.
(IF_FLOAT128): New macro.
(GEN_TEST_STRTOD): Update to optionally include _Float128 in
the tests.
(STRTOD_TEST_FOREACH): Likewise.
* sysdeps/ieee754/float128/Makefile: Insert new strtof128 and
wcstof128 functions into libc.
* sysdeps/ieee754/float128/Versions: Add exports for the above
new functions.
* sysdeps/ieee754/float128/mpn2float128.c: New file.
* sysdeps/ieee754/float128/strtod_nan_float128.h: New file.
* sysdeps/ieee754/float128/strtof128.c: New file.
* sysdeps/ieee754/float128/strtof128_l.c: New file.
* sysdeps/ieee754/float128/strtof128_nan.c: New file.
* sysdeps/ieee754/float128/wcstof128.c: New file.
* sysdeps/ieee754/float128/wcstof128_l.c: New file.
* sysdeps/ieee754/float128/wcstof128_nan.c: New fike.
* wcsmbs/Makefile: (CFLAGS-wcstof128.c): Append strtox-CFLAGS.
(CFLAGS-wcstof128_l): Likewise.
* wcsmbs/wchar.h: Include bits/floatn.h for _Float128 tests.
(wcstof128): New declaration.
(wcstof128_l): Likewise.
wint_t is a little finicky because it might be defined by stddef.h, which
belongs to the compiler.
In addition to the _types_, a bunch of other declarations shared between
wctype.h and wchar.h are factored out to their own header.
* libio/bits/types/FILE.h, libio/bits/types/__FILE.h
* wcsmbs/bits/types/mbstate_t.h, wcsmbs/bits/types/__mbstate_t.h
* wcsmbs/bits/types/wint_t.h: New single-type definition files.
* wctype/bits/wctype-wchar.h: New file holding declarations shared
between wctype.h and wchar.h.
* libio/Makefile, wcsmbs/Makefile, wctype/Makefile:
Install them.
* include/bits/types/FILE.h, include/bits/types/__FILE.h
* include/bits/types/mbstate_t.h, include/bits/types/__mbstate_t.h
* include/bits/types/wint_t.h, include/bits/wcsmbs-wchar.h:
New wrappers.
* include/stdio.h, include/wchar.h, include/wctype.h:
No need to handle __need macros.
* grp/grp.h, gshadow/gshadow.h, hurd/hurd.h, iconv/gconv.h
* libio/stdio.h, mach/mach.h, misc/mntent.h, pwd/pwd.h
* shadow/shadow.h, stdio-common/printf.h, wcsmbs/uchar.h
* wcsmbs/wchar.h, wctype/wctype.h
* sysdeps/generic/_G_config.h, sysdeps/unix/sysv/linux/_G_config.h
Use the new files instead of __need macros.
This extends tst-strtod-round with a few trivial changes
to also test the wide character variants of strto* using
similar macros to other shared tests.
The nan* functions handle their string argument by constructing a
NAN(...) string on the stack as a VLA and passing it to strtod
functions.
This approach has problems discussed in bug 16961 and bug 16962: the
stack usage is unbounded, and it gives incorrect results in certain
cases where the argument is not a valid n-char-sequence.
The natural fix for both issues is to refactor the NaN payload parsing
out of strtod into a separate function that the nan* functions can
call directly, so that no temporary string needs constructing on the
stack at all. This patch does that refactoring in preparation for
fixing those bugs (but without actually using the new functions from
nan* - which will also require exporting them from libc at version
GLIBC_PRIVATE). This patch is not intended to change any user-visible
behavior, so no tests are added (fixes for the above bugs will of
course add tests for them).
This patch builds on my recent fixes for strtol and strtod issues in
Turkish locales. Given those fixes, the parsing of NaN payloads is
locale-independent; thus, the new functions do not need to take a
locale_t argument.
Tested for x86_64, x86, mips64 and powerpc.
* stdlib/strtod_nan.c: New file.
* stdlib/strtod_nan_double.h: Likewise.
* stdlib/strtod_nan_float.h: Likewise.
* stdlib/strtod_nan_main.c: Likewise.
* stdlib/strtod_nan_narrow.h: Likewise.
* stdlib/strtod_nan_wide.h: Likewise.
* stdlib/strtof_nan.c: Likewise.
* stdlib/strtold_nan.c: Likewise.
* sysdeps/ieee754/ldbl-128/strtod_nan_ldouble.h: Likewise.
* sysdeps/ieee754/ldbl-128ibm/strtod_nan_ldouble.h: Likewise.
* sysdeps/ieee754/ldbl-96/strtod_nan_ldouble.h: Likewise.
* wcsmbs/wcstod_nan.c: Likewise.
* wcsmbs/wcstof_nan.c: Likewise.
* wcsmbs/wcstold_nan.c: Likewise.
* stdlib/Makefile (routines): Add strtof_nan, strtod_nan and
strtold_nan.
* wcsmbs/Makefile (routines): Add wcstod_nan, wcstold_nan and
wcstof_nan.
* include/stdlib.h (__strtof_nan): Declare and use
libc_hidden_proto.
(__strtod_nan): Likewise.
(__strtold_nan): Likewise.
(__wcstof_nan): Likewise.
(__wcstod_nan): Likewise.
(__wcstold_nan): Likewise.
* include/wchar.h (____wcstoull_l_internal): Declare.
* stdlib/strtod_l.c: Do not include <ieee754.h>.
(____strtoull_l_internal): Remove declaration.
(STRTOF_NAN): Define macro.
(SET_MANTISSA): Remove macro.
(STRTOULL): Likewise.
(____STRTOF_INTERNAL): Use STRTOF_NAN to parse NaN payload.
* stdlib/strtof_l.c (____strtoull_l_internal): Remove declaration.
(STRTOF_NAN): Define macro.
(SET_MANTISSA): Remove macro.
* sysdeps/ieee754/ldbl-128/strtold_l.c (STRTOF_NAN): Define macro.
(SET_MANTISSA): Remove macro.
* sysdeps/ieee754/ldbl-128ibm/strtold_l.c (STRTOF_NAN): Define
macro.
(SET_MANTISSA): Remove macro.
* sysdeps/ieee754/ldbl-64-128/strtold_l.c (STRTOF_NAN): Define
macro.
(SET_MANTISSA): Remove macro.
* sysdeps/ieee754/ldbl-96/strtold_l.c (STRTOF_NAN): Define macro.
(SET_MANTISSA): Remove macro.
* wcsmbs/wcstod_l.c (____wcstoull_l_internal): Remove declaration.
* wcsmbs/wcstof_l.c (____wcstoull_l_internal): Likewise.
* wcsmbs/wcstold_l.c (____wcstoull_l_internal): Likewise.
The implementations of strtod and related functions use
locale-specific conversions to lower case when parsing the contents of
a string NAN(n-char-sequence_opt). This has the consequence that
NAN(I) is not treated as being of that form (only the initial NAN part
is accepted). The syntax of n-char-sequence directly maps to the
ASCII letters, digits and underscore as in identifiers, so it is
unambiguous that all ASCII letters must be accepted in all locales.
This patch, relative to a tree with
<https://sourceware.org/ml/libc-alpha/2015-11/msg00258.html> (pending
review) applied and depending on that patch, fixes this problem by
checking directly for ASCII letters. This will have the side effect
of no longer accepting 'İ' (dotted 'I') inside NAN() in Turkish
locales, which seems appropriate (that letter wouldn't have been
interpreted as having any meaning in the NaN payload anyway, as not
acceptable to strtoull).
Tested for x86_64 and x86.
[BZ #19266]
* stdlib/strtod_l.c (____STRTOF_INTERNAL): Check directly for
upper case and lower case letters inside NAN(), not using TOLOWER.
* stdlib/tst-strtod-nan-locale-main.c: New file.
* stdlib/tst-strtod-nan-locale.c: Likewise.
* stdlib/Makefile (tests): Add tst-strtod-nan-locale.
[$(run-built-tests) = yes] ($(objpfx)tst-strtod-nan-locale.out):
Depend on $(gen-locales).
($(objpfx)tst-strtod-nan-locale): Depend on $(libm).
* wcsmbs/tst-wcstod-nan-locale.c: New file.
* wcsmbs/Makefile (tests): Add tst-wcstod-nan-locale.
[$(run-built-tests) = yes] ($(objpfx)tst-wcstod-nan-locale.out):
Depend on $(gen-locales).
($(objpfx)tst-wcstod-nan-locale): Depend on $(libm).
The implementations of strtol and related functions use
locale-specific conversions to upper case before determining whether a
character is a valid letter in the argument. This means that in
Turkish locales such as tr_TR.UTF-8 and tr_TR.ISO-8859-9, "i" is
interpreted as not being a valid number, when if the base passed to
strtol is 19 or more it should be interpreted as the number 18.
ISO C explicitly says "The letters from a (or A) through z (or Z) are
ascribed the values 10 through 35", so clearly intends the standard
ASCII letters (otherwise you wouldn't generally have exactly 26
letters to ascribe such values) (whereas white-space must be
identified according to the locale). In particular, 'i' and 'I' must
be understood to be in that sequence.
This patch makes the code do the case conversions and classification
in the C locale; the user's locale remains used for whitespace testing
(explicitly correct according to ISO C). Note that the way the code
worked, the only non-ASCII letter that would previously have been
accepted would have been the Turkish 'ı' (dotless 'i'), because the
uppercase version of that in Turkish locales is 'I'. This patch means
that will no longer be accepted, which seems appropriate.
Tested for x86_64 and x86.
[BZ #19242]
* stdlib/strtol_l.c (ISALPHA): Use _nl_C_locobj_ptr for locale.
(TOUPPER): Likewise.
* stdlib/tst-strtol-locale-main.c: New file.
* stdlib/tst-strtol-locale.c: Likewise.
* stdlib/Makefile (tests): Add tst-strtol-locale.
[$(run-built-tests) = yes] (LOCALES): Add tr_TR.ISO-8859-9.
[$(run-built-tests) = yes] ($(objpfx)tst-strtol-locale.out):
Depend on $(gen-locales).
* wcsmbs/tst-wcstol-locale.c: New file.
* wcsmbs/Makefile (tests): Add tst-wcstol-locale.
[$(run-built-tests) = yes] (LOCALES): Add tr_TR.UTF-8 and
tr_TR.ISO-8859-9.
[$(run-built-tests) = yes] ($(objpfx)tst-wcstol-locale.out):
Depend on $(gen-locales).
