atexit(3) is one of the cases when _exit(2) must be used instead of
exit(3).

MFC after:		3 days
Reviewed by:		mhorne, ziaee
Differential Revision:	https://reviews.freebsd.org/D54467

* Try to make the RETURN VALUES section flow better.

* Add basename(3), dirname(3), free(3) to the SEE ALSO section.

* Drop the CAVEATS section, which was obsolete the moment realpath(3)
  was added to the Single Unix Specification in 1994.

MFC after:      1 week
Sponsored by:   Klara, Inc.
Reviewed by:	kevans
Differential Revision:	https://reviews.freebsd.org/D55928

* Save prev_len after having checked for and appended a trailing slash,
  not before.  This requires us to back up if we end up returning a
  partial result, but previously we would sometimes return a partial
  result with a trailing slash and sometimes without.

* Replace strlcat() with a faster strlcpy() since we know exactly how
  far into the buffer we are.

MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	kevans
Differential Revision:	https://reviews.freebsd.org/D55914

The thread_local variable may creates another thread_local variable
inside its dtor. This new object is immediately be registered in
__cxa_thread_atexit() and need to be freed before processing another
variable.

This fixes the libcxx test thread_local_destruction_order.pass.cpp.

Reported by:    kib
Approved by:    lwhsu (mentor)
MFC after:      2 weeks
Sponsored by:   The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55826

There is no need to call execl(), which will allocate an array and copy
our arguments into it, when we can use a static array and call execve()
directly.

MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	kevans
Differential Revision:	https://reviews.freebsd.org/D55648

Our manual page states that if given a null pointer, system() returns
non-zero if the shell is available and zero if it is not.  This is
consistent with the C standard's description of system(), but it is not
what we actually do.  What we actually do is always return non-zero, as
required by POSIX.

As the POSIX rationale explains, implementing the logic required by the
C standard does not violate POSIX, since a conforming system always has
a shell, therefore the logic will always return non-zero.

Since our libc is commonly used in non-conforming situations such as
chroots or thin jails, we should implement the full logic required by
the C standard.

MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	obiwac, bnovkov, kevans
Differential Revision:	https://reviews.freebsd.org/D55484

Our manual page currently states that system() will return 127 if it
fails to execute the shell.  The actual return value is, to quote POSIX,
“as if the command language interpreter had terminated using exit(127)
or _exit(127)”.

MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	bnovkov, kevans
Differential Revision:	https://reviews.freebsd.org/D55483

Ignore SIGINT and SIGQUIT and block SIGCHLD, as POSIX requires.

To deal with the concurrency problem described in POSIX, we keep track
of the count of concurrent invocations.  We ignore and block signals
only when the counter was zero before we incremented it, and restore
them only when the counter reaches zero after we decrement it.

Note that this does not address the issue of thread cancellation.

MFC after:	1 week
Sponsored by:	Klara, Inc.
Reviewed by:	bnovkov, sef, kevans
Differential Revision:	https://reviews.freebsd.org/D55471

No need to have 4 separate manpages for these functions. Use opportunity
to change parameter names in the source from j -> i to reflect the name
used in POSIX. (The ISO C standard uses j but i is a better name
anyway.)

Reviewed by:	des, rpokala
Approved by:	rpokala
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D55361

No need to have 4 separate manpages for these functions.

Reviewed by:	ziaee, rpokala, des
Approved by:	rpokala, des
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D55360