See 8164d511d6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
for some background. Here we should really be testing MK_CLANG instead,
since that's what gates compilation of libclang_rt.
Fixes: 8164d511d6 ("libc/tests: Fix installation without MK_TOOLCHAIN")
There is some exotic conditional logic here to avoid building a
particular test if a certain UBSAN library isn't present in the
toolchain sysroot. This causes build failures for me when doing an
"installworld WITHOUT_TOOLCHAIN=", which I do frequently during tests.
I believe the problem is that SYSROOT is unset during installworld, so
the build sees the host's copy of libclang_rt.ubsan_standalone.a and
then tries to install a binary that wasn't built during buildworld. Try
to make the check a bit less fragile.
Reviewed by: dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45035
Despite looking trivial, it requires proper split of exports from libsys
and libc, proper filtering work in rtld, and operational libsys.
Reviewed by: emaste, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44075
Continue to filter the public interface (elf_aux_info()), but entierly
relocate the private interfaces (_elf_aux_info(),
__init_elf_aux_vector(), and __elf_aux_vector) to libsys.
This ensures that rtld updates the correct (only) copy of
__elf_aux_vector. After 968a18975a
updates were confused and __getosreldate was failing, causing
the system to fall back to compat compat12 syscalls in some cases.
Return to explicitly linking libc to libsys and link libthr with libc
and libsys (in that order).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D43910
The "values" test case is specifically crafted to detect the off-by-one
error previous discovered in the scalar strchrnul implementation.
Tested by: developers@, exp-run
Approved by: mjg
MFC after: 1 month
MFC to: stable/14
PR: 275785
Differential Revision: https://reviews.freebsd.org/D42925
A straightforward derivation from the stpncpy unit test.
Sponsored by: The FreeBSD Foundation
Tested by: developers@, exp-run
Approved by: mjg
MFC after: 1 month
MFC to: stable/14
PR: 275785
Differential Revision: https://reviews.freebsd.org/D42863
This adds additional unit tests validating the function for
All possible alignment offsets of source and destination.
Also extend the test to allow testing of an external stpncpy
implementation, which greatly simplifies the development of
custom implementations.
Sponsored by: The FreeBSD Foundation
Tested by: developers@, exp-run
Approved by: mjg
MFC after: 1 month
MFC to: stable/14
PR: 275785
Differential Revision: https://reviews.freebsd.org/D42519
These are patterned after the previously added (D41970)
strcmp tests, but are extended to check for various length
conditions.
Sponsored by: The FreeBSD Foundation
Tested by: developers@, exp-run
Approved by: mjg
MFC after: 1 month
MFC to: stable/14
PR: 275785
Differential Revision: https://reviews.freebsd.org/D42122
Fix "singleton" function used by regcomp() to turn character set matches
into exact character matches if a character set has exactly one
element.
The underlying cset representation is complex; most critically it
records"small" characters (codepoint less than either 128
or 256 depending on locale) in a bit vector, and "wide" characters in
a secondary array.
Unfortunately the "singleton" function uses to identify singleton sets
treated a cset as a singleton if either the "small" or the "wide" sets
had exactly one element (it would then ignore the other set).
The easiest way to demonstrate this bug:
$ export LANG=C.UTF-8
$ echo 'a' | grep '[abà]'
It should match (and print "a") but instead it doesn't match because the
single accented character in the set is misinterpreted as a singleton.
Reviewed by: kevans, yuripv
Obtained from: illumos
Differential Revision: https://reviews.freebsd.org/D43149
This new unit test verifies that if there are multiple
matches, the first match is returned, ignoring later
matches.
Approved by: mjg (blanket, via IRC)
MFC after: 1 week
MFC to: stable/14
This changeset add a new set of tests that comprehensively test strcmp() on
various alignments of the input. This made it easy to smoke out many
exciting new bugs in the new SSE strcmp() implementation from D41971.
MFC after: 1 week
Reviewed by: ngie
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41970
These sys/cdefs.h are not needed. Purge them. They are mostly left-over
from the $FreeBSD$ removal. A few in libc are still required for macros
that cdefs.h defines. Keep those.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42385
The four functions more or less perform the same operation.
Reuse the same unit test with slight changes so we can cover
them all. Constant-time operation is not verified for the
timingsafe_* functions.
Sponsored by: The FreeBSD Foundation
Approved by: ngie
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41528
Extend the tests to permit loading an external memcmp function
and testing it over using the libc version. This was added by the
example of other tests in the test suite doing the same thing and
helped tremendously in development.
This change was originally part of D41442 but was taken out to
permit separate review as extrapolated from @ngie's request in
D41349.
Sponsored by: FreeBSD Foundation
Approved by: ngie
Differential Revision: https://reviews.freebsd.org/D41528
This extends the strcspn() unit tests to catch mistakes in the
implementation that only appear when a mismatch occurs in a certain
position of the string against a certain position of the set.
See also: 52d4a4d4e0
Sponsored by: The FreeBSD Foundation
Approved by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41821
To cover the new optimised amd64 strspn(3) SIMD implementation, extend
the previously written strcspn(3) unit test to also cover strspn(3).
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41567
We currently use the NetBSD test suite to cover strcspn(3). It only
contains a very rudimentary test of this function. This all new set
of unit tests for the FreeBSD test suite should cover many more edge
cases relating to alignment issues.
Sponsored by: The FreeBSD Foundation
Approved by: mjg
MFC after: 1 week
MFC to: stable/14
Differential Revision: https://reviews.freebsd.org/D41557
This adds test cases for %wN and %wfN to the printf(3) and scanf(3) tests.
While here, fix a few nits in the N2630 test cases.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D41743
Also supply CFLAGS+=-fno-builtin to ensure our unit tests
actually test libc functions and not clang's builtins.
Sponsored by: FreeBSD Foundation
Approved by: kevans
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40729
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Fix newlocale() overwriting the locale name in collate object
when same instance was used for those locales, and querylocale()
reporting unexpected value for LC_COLLATE_MASK.
PR: 255646, 269375
Reviewed by: markj, bapt (previous version)
Differential Revision: https://reviews.freebsd.org/D30146
strfmon_l does not take fully into consideration the explicitly passed
locale to perform the formatting.
Parallel universe bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=19633
Obtained from: Darwin
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
Attempt to test the correctness of strfmon_l(3).
Items marked with XXX represent an invalid output.
Obtained from: e7eba0044f
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
Otherwise strfmon(3) could overflow the buffer.
Here is mostly done for correctness and illustrative purposes, as there
is no chance it could actually happen.
Reviewed by: kib
PR: 267410
Github PR: #620
MFC after: 1 week
There is a bug when formatting two consecutive values using fixed-widths
and the values need padding. This was because the value of pad_size
was zeroed only every other time.
Format Before After
[%8n] [%8n] [ $123.45] [ $123.45] [ $123.45] [ $123.45]
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Fix an edge case by printing the required space when, the currency
symbol succeeds the value, a space separates the sign from the value and
the sign position precedes the quantity and the currency symbol.
In other words:
n_cs_precedes = 0
n_sep_by_space = 2
n_sign_posn = 1
From The Open Group's localeconv[1]:
> When {p,n,int_p,int_n}_sep_by_space is 2:
> If the currency symbol and sign string are adjacent, a space separates
> them; otherwise, a space separates the sign string from the value.
Format Before After
[%n] [-123.45¤] [- 123.45¤]
[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/localeconv.html
Obtained from: Darwin
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Take into consideration the possibility of quantities enclosed by
parentheses when aligning.
Matches the examples from The Open Group's:
Format Before After
%(#5n [$ 123.45] [ $ 123.45 ] Use an alternative pos/neg style
[($ 123.45)] [($ 123.45)]
[$ 3,456.78] [ $ 3,456.78 ]
%!(#5n [ 123.45] [ 123.45 ] Disable the currency symbol
[( 123.45)] [( 123.45)]
[ 3,456.78] [ 3,456.78 ]
https://pubs.opengroup.org/onlinepubs/9699919799/functions/strfmon.html
SD5-XSH-ERN-29 is applied, updating the examples for %(#5n and %!(#5n.
Obtained from: Darwin
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
The international currency symbol (int_curr_symbol) has a mandatory
SPACE character as the last character.
Trim this space after reading it, otherwise this extra space will always
be printed when displaying the int_curr_symbol.
Fixes the output when the international currency format is selected
(%i).
Locale Format Before After
en_US.UTF-8 [%i] [USD 123.45] [USD123.45]
fr_FR.UTF-8 [%i] [123,45 EUR ] [123,45 EUR]
Note that the en_US.UTF-8 locale states that no space should be printed
between the currency symbol and the value (sep_by_space = 0).
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
Avoid an out-of-bounds access when trying to set the space_char using an
international currency format (%i) and the C/POSIX locale.
The current code tries to read the SPACE from int_curr_symbol[3]:
currency_symbol = strdup(lc->int_curr_symbol);
space_char = *(currency_symbol+3);
But on C/POSIX locales, int_curr_symbol is empty.
Three implementations have been examined: NetBSD[1], Darwin[2], and
Illumos[3]. Only NetBSD has fixed it[4].
Darwin and NetBSD also trim the mandatory final SPACE character after
reading it.
Locale Format Darwin/NetBSD FreeBSD/Illumos
en_US.UTF-8 [%i] [USD123.45] [USD 123.45]
fr_FR.UTF-8 [%i] [123,45 EUR] [123,45 EUR ]
This commit only fixes the out-of-bounds access.
[1]: https://github.com/NetBSD/src/blob/trunk/lib/libc/stdlib/strfmon.c
[2]: https://opensource.apple.com/source/Libc/Libc-1439.141.1/stdlib/NetBSD/strfmon.c.auto.html
[3]: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/locale/strfmon.c
[4]: 3d7b5d498a
Reviewed by: kib
PR: 267282
Github PR: #619
MFC after: 1 week
glibc-based interface.
Unfortunately, the glibc maintainers, despite knowing the existence
of the FreeBSD qsort_r(3) interface in 2004 and refused to add the
same interface to glibc based on grounds of the lack of standardization
and portability concerns, has decided it was a good idea to introduce
their own qsort_r(3) interface in 2007 as a GNU extension with a
slightly different and incompatible interface.
With the adoption of their interface as POSIX standard, let's switch
to the same prototype, there is no need to remain incompatible.
C++ and C applications written for the historical FreeBSD interface
get source level compatibility when building in C++ mode, or when
building with a C compiler with C11 generics support, provided that
the caller passes a fifth parameter of qsort_r() that exactly matches
the historical FreeBSD comparator function pointer type and does not
redefine the historical qsort_r(3) prototype in their source code.
Symbol versioning is used to keep old binaries working.
MFC: never
Relnotes: yes
Reviewed by: cem, imp, hps, pauamma
Differential revision: https://reviews.freebsd.org/D17083
