src/lib/libc/tests/stdlib, branch releng/11.3

MFC r316213:

2017-04-23T20:32:46Z

Implement the memset_s(3) function as specified by the C11 ISO/IEC 9899:2011 Appendix K 3.7.4.1. MFC r316258: Only activate __EXT1_VISIBLE block when using sys/errno.h in userspace.

MFC r311925,r311968,r311969,r312102,r312108:

2017-02-04T16:47:56Z

r311925: Import testcase updates with code contributed back to NetBSD This also (inadvertently) contains an update to contrib/netbsd-tests/lib/libc/sys/t_wait.c (new testcases). In collaboration with: christos@NetBSD.org r311968: Fix lib/libc/sys/access_test after r311925 sys/param.h needs to be #included in order for __FreeBSD_version to be checked r311969: Remove __HAVE_LONG_DOUBLE #define from t_strtod.c and place it in Makefile This is to enable support in other testcases Inspired by lib/msun/tests/Makefile . r312102: Note that sys/types.h is required on FreeBSD for kqueue(2), unlike NetBSD r312108: Delete trailing whitespace and use __arraycount instead of nitems in contrib code

MFC r305358:

2016-12-03T02:47:16Z

Update contrib/netbsd-tests with new content from NetBSD This updates the snapshot from 09/30/2014 to 08/11/2016 This brings in a number of new testcases from upstream, most notably: - bin/cat - lib/libc - lib/msun - lib/libthr - usr.bin/sort lib/libc/tests/stdio/open_memstream_test.c was moved to lib/libc/tests/stdio/open_memstream2_test.c to accomodate the new open_memstream test from NetBSD. Tested on: amd64 (VMware fusion VM; various bare metal platforms); i386 (VMware fusion VM); make tinderbox

MFC r307227 and r307343:

2016-10-29T14:41:22Z

Improve typing of POSIX search tree functions. Back in 2015 when I reimplemented these functions to use an AVL tree, I was annoyed by the weakness of the typing of these functions. Both tree nodes and keys are represented by 'void *', meaning that things like the documentation for these functions are an absolute train wreck. To make things worse, users of these functions need to cast the return value of tfind()/tsearch() from 'void *' to 'type_of_key **' in order to access the key. Technically speaking such casts violate aliasing rules. I've observed actual breakages as a result of this by enabling features like LTO. I've filed a bug report at the Austin Group. Looking at the way the bug got resolved, they made a pretty good step in the right direction. A new type 'posix_tnode' has been added to correspond to tree nodes. It is still defined as 'void' for source-level compatibility, but in the very far future it could be replaced by a proper structure type containing a key pointer.

MFC r303795:

2016-08-20T11:58:23Z

Add __cxa_thread_atexit(3) API implementation.

Merge ^/user/ngie/release-pkg-fix-tests to unbreak how test files are installed

2016-05-04T23:20:53Z

after r298107 Summary of changes: - Replace all instances of FILES/TESTS with ${PACKAGE}FILES. This ensures that namespacing is kept with FILES appropriately, and that this shouldn't need to be repeated if the namespace changes -- only the definition of PACKAGE needs to be changed - Allow PACKAGE to be overridden by callers instead of forcing it to always be `tests`. In the event we get to the point where things can be split up enough in the base system, it would make more sense to group the tests with the blocks they're a part of, e.g. byacc with byacc-tests, etc - Remove PACKAGE definitions where possible, i.e. where FILES wasn't used previously. - Remove unnecessary TESTSPACKAGE definitions; this has been elided into bsd.tests.mk - Remove unnecessary BINDIRs used previously with ${PACKAGE}FILES; ${PACKAGE}FILESDIR is now automatically defined in bsd.test.mk. - Fix installation of files under data/ subdirectories in lib/libc/tests/hash and lib/libc/tests/net/getaddrinfo - Remove unnecessary .include s (some opportunistic cleanup) Document the proposed changes in share/examples/tests/tests/... via examples so it's clear that ${PACKAGES}FILES is the suggested way forward in terms of replacing FILES. share/mk/bsd.README didn't seem like the appropriate method of communicating that info. MFC after: never probably X-MFC with: r298107 PR: 209114 Relnotes: yes Tested with: buildworld, installworld, checkworld; buildworld, packageworld Sponsored by: EMC / Isilon Storage Division

MFH

2016-03-10T21:16:01Z

DIRDEPS_BUILD: Connect MK_TESTS.

2016-03-09T22:46:01Z

Sponsored by: EMC / Isilon Storage Division

First pass to fix the 'tests' packages.

2016-02-02T22:26:49Z

Let tsearch()/tdelete() use an AVL tree.

2015-12-22T18:12:11Z

The existing implementations of POSIX tsearch() and tdelete() don't attempt to perform any balancing at all. Testing reveals that inserting 100k nodes into a tree sequentially takes approximately one minute on my system. Though most other BSDs also don't use any balanced tree internally, C libraries like glibc and musl do provide better implementations. glibc uses a red-black tree and musl uses an AVL tree. Red-black trees have the advantage over AVL trees that they only require O(1) rotations after insertion and deletion, but have the disadvantage that the tree has a maximum depth of 2*log2(n) instead of 1.44*log2(n). My take is that it's better to focus on having a lower maximum depth, for the reason that in the case of tsearch() the invocation of the comparator likely dominates the running time. This change replaces the tsearch() and tdelete() functions by versions that create an AVL tree. Compared to musl's implementation, this version is different in two different ways: - We don't keep track of heights; just balances. This is sufficient. This has the advantage that it reduces the number of nodes that are being accessed. Storing heights requires us to also access all of the siblings along the path. - Don't use any recursion at all. We know that the tree cannot 2^64 elements in size, so the height of the tree can never be larger than 96. Use a 128-bit bitmask to keep track of the path that is computed. This allows us to iterate over the same path twice, meaning we can apply rotations from top to bottom. Inserting 100k nodes into a tree now only takes 0.015 seconds. Insertion seems to be twice as fast as glibc, whereas deletion has about the same performance. Unlike glibc, it uses a fixed amount of memory. I also experimented with both recursive and iterative bottom-up implementations of the same algorithm. This iterative top-down version performs similar to the recursive bottom-up version in terms of speed and code size. For some reason, the iterative bottom-up algorithm was actually 30% faster for deletion, but has a quadratic memory complexity to keep track of all the parent pointers. Reviewed by: jilles Obtained from: https://github.com/NuxiNL/cloudlibc Differential Revision: https://reviews.freebsd.org/D4412