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
(cherry picked from commit c082e5656417945bfa567114c60969844f3d7bdf)
* 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
(cherry picked from commit 1aecb32021ce46d812db36b9037cdc6f423575f9)
* 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
(cherry picked from commit 99d295e471bc362a7927047c89472e1ee2d0da6b)
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
(cherry picked from commit 40e52e0edd038460a2a2aca017b3ac5a513fe37b)
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
(cherry picked from commit 8ae3f44991948cc97b09adc248a9a46db71bf9e0)
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
(cherry picked from commit 7305604b29d3db29c9bb5de6e7a25829fb541d1e)
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
(cherry picked from commit 6e589e6e8e64793adb437c561ec084dbb6ad1ced)
Mainly rename numerator parameter of div(3) and ldiv(3) from num to
numer, and explicitly specify what "numer", "denom", and "rem" mean in
the manpages.
MFC after: 3 days
Obtained from: https://github.com/apple-oss-distributions/libc (partially)
Sponsored by: Klara, Inc.
(cherry picked from commit 0bba277f2223a31e4453ade39be110b1b3aeb1dd)
This new function computes the alignment of a pointer.
It is part of ISO/IEC 9899:2024, the new C standard.
If the pointer is a null pointer, null is returned.
I have tried to write an implementation that can cope
with traditional address-based architectures, even if
size_t and uintptr_t are of different length. Adjustments
may be needed for CHERI though.
A man page is provided, too. No unit test for now.
Reviewed by: kib, imp, ziaee (manpages), pauamma@gundo.com
Approved by: markj (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D53673
(cherry picked from commit 6c57e368eb1777f6097158eeca2fcc175d068dba)
This function from OpenBSD is a hybrid of reallocarray() and calloc().
It reallocates an array, clearing any newly allocated items.
reallocarray() ultimately originates from OpenBSD.
The source is taken from lib/libopenbsd, which now no longer has the
function unless when bootstrapping (needed for mandoc).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52863
(cherry picked from commit 42664610795bc0a728851ba6223fcf9b93801167)
If the locale's positive_sign and negative_sign values would both be
returned by localeconv() as empty strings, strfmon() shall behave as if
the negative_sign value was the string "-".
This occurs with the C locale. The implementation previously assigned
"0" to sign_posn (parentheses around the entire string); now it assigns
it to "1" (sign before the string) when it is undefined (CHAR_MAX).
Austin Group Defect 1199[1] is applied, changing the requirements for
the '+' and '(' flags.
[1]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53913
(cherry picked from commit cf85e7034ad5640b18a3b68d6b291b7bf89bfc80)
According to the Open Group Base Specifications Issue 8[1], strfmon(3)
should return EINVAL when the '+' flag was included in a conversion
specification and the locale's positive_sign and negative_sign values
would both be returned by localeconv(3) as empty strings.
Austin Group Defect 1199[2] is applied, adding the [EINVAL] error.
[1]: https://pubs.opengroup.org/onlinepubs/9799919799/functions/strfmon.html
[2]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53912
(cherry picked from commit 1fd018972a18b682521bb8f004dfd162327e5db2)
We've been mostly POSIX-conforming since r236400 and fully since r240410,
which fixed a corner case where a missing non-leaf directory would be
reported as ENOTDIR instead of ENOENT.
Sponsored by: Klara, Inc.
Fixes: 7877ed7ce3 ("Avoid mapping ENOENT to ENOTDIR for non-existent path components.")
Reviewed by: ziaee, markj
Differential Revision: https://reviews.freebsd.org/D53027
(cherry picked from commit 7c66667d45e95af59f59e41ef169119a974a6be1)
If lstat() fails with EACCES or ENOTDIR, the path we need to return in
the caller-provided buffer is that of the parent directory (which is
either unreadable or not a directory; the latter can only happen in the
case of a race) rather than that of the child we attempted to stat.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D53025
(cherry picked from commit 1406de21e176d8700240ac9e473df007cd41eec1)
gcc doesn't like something about the initializer that comes with
jemalloc. Since it's vendor code, make this warning not an error
for -Werror purposes.
Sponsored by: Netflix
This brings in a merge from jemalloc 5.3.0. It's almost fully scripted, except:
Three conflicts resolved by hand:
include/jemalloc/internal/test_hooks.h Use the new name
src/extent.c Use the new code
src/jemalloc.c Use the new code since je_realloc has moved
The script is recorded in FREEBSD-upgrade. The old script did svn
commands that were basically a rebase of our changes. This update has a
series of diff reduction changes before this.
Note: I'd planned on fixing the above three conflicts with commits, but
ran out of time when I did this work in January. I got discouraged when
jemalloc was EOL'd and didn't pick this back up. I did the above by hand
to get this into FreeBSD 15.0
This work is a repeat of the work by Minsoo Choo who did all these
changes and created a pull request. Given the importance of jemalloc, I
audited these changes by redoing them in this series of commits (and
with the script that was checked in). I did this to confince myself and
anybody else in doubt that there was no supply chain attack. The diffs
between this series of commits and Minsoo's work are minor (though the
version skew makes adds some noise). Interested parties can independent
audit each step, I hope. I've listed Minsoo as a co-author since without
his pull request to test again, this wouldn't have been possible.
Thanks to brooks@ for help with getting the jemalloc 3 ABI compat
symbols right.
Co-authored-by: Minsoo Choo <minsoochoo0122@proton.me>
Pull Request: https://github.com/freebsd/freebsd-src/pull/1337
Sponsored by: Netflix
As pointed out in the PR and the article linked below, the switch to
insertion sort in the BSD qsort code is based on a misunderstanding of
Knuth's TAOCP and is actually a pessimization. As demonstrated by the
added test, it is trivially easy to construct pathological input which
results in quadratic runtime. Without that misguided optimization, the
same input runs in nearly linearithmic time.
https://www.raygard.net/2022/02/26/Re-engineering-a-qsort-part-3
PR: 287089
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D51907
This is a calque of the NetBSD function of the same name.
MFC after: never
Relontes: yes
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D49979
science/dlib-cpp reveals an interesting scenario that works fine on
other platforms but not on FreeBSD; notably, it ends up creating a new
global object from some destructor which is called during
__cxa_finalize. This breaks when libdlib is dlopen()ed and then
subsequently dlclose()ed, as we never end up invoking the created
object's dtor until program exit when the shlib is already unmapped.
Fix it by noting when we're in the middle of __cxa_finalize for a dso,
and then restarting the search if __cxa_atexit() was called in the
middle somewhere.
We wait until we've processed the initial set before starting over and
processing the newly added handlers as if it were a complete set of
handlers added during runtime. The alternative is calling them as
they're added to maintain a LIFO in terms of total ordering, but in
theory a constructor could add another global object that also needs to
be destroyed, and that object needs to be destroyed after the one that
constructed it to avoid creating unexpected lifetime issues.
This manifests in the pdlib PHP extension for dlib crashing, see [0].
[0] https://github.com/goodspb/pdlib/issues/39
PR: 285870
Reviewed by: kevans (also supplied commit message)
MFC after: 1 week
We don't need to use an interposable symbol for this purpose and it's
simpler to just call the syscall in libsys. This resolves a bug where
we were incorrectly using __realpathat in libc not libsys.
While here, drop support for running on a FreeBSD 12 kernel and simplify
includes.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D49048
Make it easire to update jemalloc by moving the FreeBSD specific files
and the generated files into lib/libc. This allows us to regenerate them
more easily, and emphasizes a bit that we may have to regenerate stuff
from upstream.
This is necessary to also unthin the import from the vendor branch as
well (which will be needed to simplify the imports in the future since
we are trying to use contrib/jemalloc for two different things).
No functional change.
Sponsored by: Netflix
The more generated things that are in contrib/jemalloc tree, the more
chances for interference goes way up. So, move this file into our
lib/libc tree. I didn't add a 'generated file' line / info, but this is
funky enough I don't think we need that. We do add things to the man
page, and that should be tracked in the contrib/jemalloc tree to allow
better importing experience.
Sponsored by: Netflix
These were reported by `mandoc -T lint ...` as warnings:
- unusual Xr order
- unusual Xr punctuation
Fixes made by script in https://github.com/Tarsnap/freebsd-doc-scripts
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1464
and allow to revert it back to 48 with WITHOUT_JEMALLOC_LG_VADDR_WIDE build
option.
Reviewed by: andrew, emaste
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46686
Don't provide default linkage for jemalloc 3.0 compatability symbols.
We stopped declaring these interfaces with the introduction of jemalloc
4.0 prior to FreeBSD 11.0. Any code using them would have had to
declare them manually so stop declaring them and export the symbols
directly for compatability. Arguably they should be x86 only as they
were never declared on other Tier-1 architectures.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D46407
The immediately obvious and attractive targets from <stdlib.h> are
arc4random_buf(3) and realpath(3) -- scraping the header didn't reveal
much else of interest.
Reviewed by: markj
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D45681
When checking for the destructor pointer belonging to some still
loaded dso, do not limit the possible dso to the one instantiated the
destructor. For instance, dso could set up the dtr pointer to a function
from libcxx.
PR: 278701
Reported by: vd
Reviewed by: dim, emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D45074
exit(3) man page shows __cxa_atexit(3,) instead of __cxa_atexit(3), in a
particular section. It seems the comma gets inside the parenthesis and
with an extra space, it can be viewed as expected.
Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1006
libc sources assume C99 or even C11 compiler already, unlike headers.
There is no reason to obfuscate the basic C constructs.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
