libc/stdlib: Port strtonumx() from Illumos

Add strtonumx(), a companion to strtonum(3) that preserves its safety
and error-reporting semantics while allowing the caller to specify a
conversion base,

libc/stdlib: Port strtonumx() from Illumos

Add strtonumx(), a companion to strtonum(3) that preserves its safety
and error-reporting semantics while allowing the caller to specify a
conversion base, similar to the strtol(3) family of functions.

Reviewed by: emaste, kib, ziaee
Obtained from: https://www.illumos.org/issues/15365
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54270

show more ...

libc: add glibc-compatible tdestroy(3)

The function clears the whole tree.

Relnotes: yes
Reviewed by: alc, emaste
Discussed with: dougm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differ

libc: add glibc-compatible tdestroy(3)

The function clears the whole tree.

Relnotes: yes
Reviewed by: alc, emaste
Discussed with: dougm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54365

show more ...

lib/libc: implement C23 memalignment()

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.

lib/libc: implement C23 memalignment()

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

show more ...

lib/libc: add recallocarray()

This function from OpenBSD is a hybrid of reallocarray() and calloc().
It reallocates an array, clearing any newly allocated items.
reallocarray() ultimately originates

lib/libc: add recallocarray()

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

show more ...

libc: Add getenv_r() function.

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://

libc: Add getenv_r() function.

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

show more ...

libc: Remove empty comments in Symbol.map

These were left over from $FreeBSD$ removal.

Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D42612

Remove $FreeBSD$: one-line .h pattern

Remove /^\s*\*+\s*\$FreeBSD\$.*$\n/

Revert "libc: Implement bsort(3) a bitonic type of sorting algorithm."

Some points for the future:
- libc is not the right place for sorting algorithms.
Probably libutil is better suited for thi

Revert "libc: Implement bsort(3) a bitonic type of sorting algorithm."

Some points for the future:
- libc is not the right place for sorting algorithms.
Probably libutil is better suited for this purpose or
a dedicated libsort. Should move all sorting algorithms
away from libc eventually.
- CheriBSD uses capabilities for memory access, and could
benefit from a standard memswap() function.
- Do something about qsort() in FreeBSD's libc like:
- Mark it deprecated on FreeBSD, as a first step,
due to missing limits on CPU time.
- Audit the use of qsort() in the FreeBSD base system
and consider swapping to other existing sorting
algorithms.

Discussed with: brooks@

Differential Revision: https://reviews.freebsd.org/D36493

This reverts commit a7469c9c0a504a5e6e9b89e148cd78df5e67ff7f.
This reverts commit 7d65a450cdcc7cc743f2ecd114ba3428a21c0033.
This reverts commit 8dcf3a82c54cb216df3213a013047907636a01da.

show more ...

libc: Implement bsort(3) a bitonic type of sorting algorithm.

The bsort(3) algorithm works by swapping objects, similarly to qsort(3),
and does not require any significant amount of additional memor

libc: Implement bsort(3) a bitonic type of sorting algorithm.

The bsort(3) algorithm works by swapping objects, similarly to qsort(3),
and does not require any significant amount of additional memory.

The bsort(3) algorithm doesn't suffer from the processing time issues
known the plague the qsort(3) family of algorithms, and is bounded by
a complexity of O(log2(N) * log2(N) * N), where N is the number of
elements in the sorting array. The additional complexity compared to
mergesort(3) is a fair tradeoff in situations where no memory may
be allocated.

The bsort(3) APIs are identical to those of qsort(3), allowing for
easy drop-in and testing.

The design of the bsort(3) algorithm allows for future parallell CPU
execution when sorting arrays. The current version of the bsort(3)
algorithm is single threaded. This is possible because fixed areas
of the sorting data is compared at a time, and can easily be divided
among different CPU's to sort large arrays faster.

Reviewed by: gbe@, delphij@, pauamma_gundo.com (manpages)
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36493

show more ...

Add GNU glibc compatible secure_getenv

Add mostly glibc and msl compatible secure_getenv. Return NULL if
issetugid() indicates the process is tainted, otherwise getenv(x). The
rational behind this

Add GNU glibc compatible secure_getenv

Add mostly glibc and msl compatible secure_getenv. Return NULL if
issetugid() indicates the process is tainted, otherwise getenv(x). The
rational behind this is the fact that many Linux applications use this
function instead of getenv() as it's widely consider a, "best
practice".

Reviewed by: imp, mjg (feedback)
Pull Request: https://github.com/freebsd/freebsd-src/pull/686
Signed-off-by: Lucy Marsh <seafork@disroot.org>

show more ...

xlocale: garbage collect references to strtoq_l/strtouq_l

These were explicitly never implemented (see
lib/libc/locale/DESIGN.xlocale), but were referenced in the
manpage and the symbol map.

Fixes:

xlocale: garbage collect references to strtoq_l/strtouq_l

These were explicitly never implemented (see
lib/libc/locale/DESIGN.xlocale), but were referenced in the
manpage and the symbol map.

Fixes: 3c87aa1d3dc ("Implement xlocale APIs from Darwin")
Reported by: ld.lld 16 being --no-undefined-version by default
Reviewed by: theraven, emaste
Sponsored by: https://www.patreon.com/valpackett
Pull Request: https://github.com/freebsd/freebsd-src/pull/679
Differential Revision: https://reviews.freebsd.org/D38408

show more ...

Alter the prototype of qsort_r(3) to match POSIX, which adopted the
glibc-based interface.

Unfortunately, the glibc maintainers, despite knowing the existence
of the FreeBSD qsort_r(3) interface in

Alter the prototype of qsort_r(3) to match POSIX, which adopted the
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

show more ...

libc: add clearenv function

The clearenv(3) function allows us to clear all environment
variable in one shot. This may be useful for security programs that
want to control the environment or what va

libc: add clearenv function

The clearenv(3) function allows us to clear all environment
variable in one shot. This may be useful for security programs that
want to control the environment or what variables are passed to new
spawned programs.

Reviewed by: scf, markj (secteam), 0mp (manpages)
Differential Revision: https://reviews.freebsd.org/D28223

show more ...

Further refinements of ptsname_r(3) interface:

- Hide ptsname_r under __BSD_VISIBLE for now as the specification
is not finalized at this time.
- Keep Symbol.map sorted.
- Avoid the interposin

Further refinements of ptsname_r(3) interface:

- Hide ptsname_r under __BSD_VISIBLE for now as the specification
is not finalized at this time.
- Keep Symbol.map sorted.
- Avoid the interposing of ptsname_r(3) from an user application
from breaking ptsname(3) by making the implementation a static
method and call the static function from ptsname(3) instead.

Reported by: kib
Reviewed by: kib, jilles
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26845

show more ...

Implement ptsname_r.

MFC after: 2 weeks
PR: 250062
Reviewed by: jilles, 0mp, Ray <i maskray me>
Differential Revision: https://reviews.freebsd.org/D26647

Merge ^/head r357368 through r357388.

rand(3): Replace implementation with one backed by random(3) algorithm

rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shi

rand(3): Replace implementation with one backed by random(3) algorithm

rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shipped since
2001: r73156.

The justification provided at the time for not using random(3) was that
rand_r(3) could not be made to use the same algorithm. That is still
true. However, the irrelevance of rand_r(3) is increasingly obvious.
Since that time, POSIX has marked the interface obsolescent. rand_r(3)
never became part of the standard C library. If not for API
compatibility reasons, I would just remove rand_r(3) entirely.

So, I do not believe it is a problem for rand_r(3) and rand(3) to
diverge.

The 12 ABI is maintained with compatibility definitions, but this
revision does subtly change the API of rand(3). The sequences of
pseudorandom numbers produced in programs built against new versions of
libc will differ from programs built against prior versions of libc.

Reviewed by: kevans, markm
MFC after: no
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23290

show more ...

Merge ^/head r356848 through r356919.

Add qsort_s(3). Apart from the constraints, it also makes it easier
to port software written for Linux variant of qsort_r(3).

Reviewed by: kib, arichardson
MFC after: 2 weeks
Relnotes: yes
Sponsore

Add qsort_s(3). Apart from the constraints, it also makes it easier
to port software written for Linux variant of qsort_r(3).

Reviewed by: kib, arichardson
MFC after: 2 weeks
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23174

show more ...

Deprecate sranddev(3) API

It serves no useful purpose and wasn't as popular as its equally meritless
cousin, srandomdev(3).

Setting aside the problems with rand(3) in general, the problem with this

Deprecate sranddev(3) API

It serves no useful purpose and wasn't as popular as its equally meritless
cousin, srandomdev(3).

Setting aside the problems with rand(3) in general, the problem with this
interface is that the seed isn't shared with the caller (other than by
attacking the output of the generator, which is trivial, but not a hallmark of
pleasant API design). The (arguable) utility of rand(3) or random(3) is as a
semi-fast simulation generator which produces consistent results from a given
seed. These are mutually at odd. Furthermore, sometimes people got the
mistaken impression that a high quality random seed meant a weak generator like
rand(3) or random(3) could be used for things like cryptographic key
generation. This is absolutely not so.

The API was never part of a standard and was not widely used in tree. Existing
in-tree uses have all been removed.

Possible replacement in out of tree codebases:

char buf[3];
time_t t;

time(t);
strftime(buf, sizeof(buf), "%S", gmtime(&t));
srand(atoi(buf));

Relnotes: yes

show more ...

MFHead @347527

Sponsored by: The FreeBSD Foundation

Fix order of destructors between main binary and libraries.

Since inits for the main binary are run from rtld (for some time), the
rtld_exit atexit(3) handler, which is passed from rtld to the progr

Fix order of destructors between main binary and libraries.

Since inits for the main binary are run from rtld (for some time), the
rtld_exit atexit(3) handler, which is passed from rtld to the program
entry and installed by csu, is installed after any atexit(3) handlers
installed by main binary constructors. This means that rtld_exit() is
fired before main binary handlers.

Typical C++ static constructors are executed from init (either binary
or libs) but use atexit(3) to ensure that destructors are called in
the right order, independent of the linking order. Also, C++
libraries finalizers call __cxa_finalize(3) to flush library'
atexit(3) entries. Since atexit(3) entry is cleared after being run,
this would be mostly innocent, except that, atexit(rtld_exit) done
after main binary constructors, makes destructors from libraries
executed before destructors for main.

Fix by reordering atexit(rtld_exit) before inits for main binary, same
as it happened when inits were called by csu. Do it using new private
libc symbol with pre-defined ABI.

Reported. tested, and reviewed by: kan
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

show more ...

libc/stdlib: Port strtonumx() from Illumos

Add strtonumx(), a companion to strtonum(3) that preserves its safety
and error-reporting semantics while allowing the caller to specify a
conversion base,

libc/stdlib: Port strtonumx() from Illumos

Add strtonumx(), a companion to strtonum(3) that preserves its safety
and error-reporting semantics while allowing the caller to specify a
conversion base, similar to the strtol(3) family of functions.

Reviewed by: emaste, kib, ziaee
Obtained from: https://www.illumos.org/issues/15365
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54270

show more ...

libc: add glibc-compatible tdestroy(3)

The function clears the whole tree.

Relnotes: yes
Reviewed by: alc, emaste
Discussed with: dougm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differ

libc: add glibc-compatible tdestroy(3)

The function clears the whole tree.

Relnotes: yes
Reviewed by: alc, emaste
Discussed with: dougm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54365

show more ...

lib/libc: implement C23 memalignment()

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.

lib/libc: implement C23 memalignment()

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

show more ...