Move to sys/_offsetof.h and use __builtin_offsetof() instead of
__offsetof to avoid reintroducing sys/cdefs.h polution in stddef.h.
This has the side effect of allowing sys/stddef.h to be included after
stddef.h which can happen in compatability headers.
Effort: CHERI upstreaming
Sponsored by: DARPA, AFRL
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D55307
I'd missed that stddef.h is standalone and isn't a copy of sys/stddef.h
in my initial merge.
Effort: CHERI upstreaming
Reviewed by: kib
Sponsored by: Innovate UK
Fixes: dca634d154 ("new type: ptraddr_t")
Differential Revision: https://reviews.freebsd.org/D55305
Include sys/types.h by exterr.h, since size_t is used.
Drop include of sys/exterr_cat.h, it is useless for the only prototype
provided.
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55337
It takes exactly three arguments of known type.
Tweak the types of various resultproc_t functions to match the type (mostly
added const to struct pointers) allowing us to drop casts.
Effort: CHERI upstreaming
Reviewed by: vangyzen, glebius
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54941
The `eachresult` argument is documented to take a function pointer of
type:
bool_t (*)(caddr_t, struct sockaddr_in *)
It was declared to take a resultproc_t which has historically been
declared to be:
bool_t (*resultproc_t)(caddr_t, ...);
This overlapped well enough for currently supported ABIs where variadic
arguments are passed in registers, but this declaration is misaligned
with the documentation (resultproc_t takes three arguments) and will be
fixed in a followup commit.
Fix the type to be non-variadic, matching callbacks, and define a
convenience type of as most callbacks take something other than a char *
as their first argument and need to be cast.
Effort: CHERI upstreaming
Reviewed by: ngie, glebius, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D54940
If execfd is set, the fexecve(2) is used by posix_spawn() instead of the
provided path.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54862
The type of xdrproc_t is clearly defined in the comments as a function
with two arguments, an XDR * and a void * (sometimes spelled caddr_t).
It was initialy defined as:
typedef bool_t (*xdrproc_t)();
At some point people started giving it a non-empty argument list.
Unfortunatly, there has been widespread disagreement about how arguments
are passed. There seems to have been a widespread view that it should
be allowed to pass three argument function pointer to xdrproc_t. Most
notable is xdr_string which takes a maximum length parameter. This lead
to all sorts of prototypes (all of which have been present in the
FreeBSD source tree):
FreeBSD userspace (nominally from tirpc, but seemingly local):
typedef bool_t (*xdrproc_t)(XDR *, ...);
FreeBSD kernel, glibc:
typedef bool_t (*xdrproc_t)(XDR *, void *, ...);
rcp/xdr.h with _KERNEL defined (not used?):
typedef bool_t (*xdrproc_t)(XDR *, void *, u_int);
gssrpc (in krb5) and Linux kernel:
typedef bool_t (*xdrproc_t)(XDR *, void *);
For two argument functions on current ABIs, these all equivalent as
these arguments are passed in registers regardless of decleration and
definition, but we end up with two problems:
- xdr_free((xdrproc_t)xdr_string, ...) calls xdr_string with no third
argument and (at least on FreeBSD) may fail to free memory if the
string is shorter than the value lying around in the third argument
register. There are no instance of this in tree, but I found some
with Debian code search, in particular in OpenAFS.
- Under CheriABI, variadic arguments are passed in a separate,
bounded array so theses prototypes aren't equilvalent to the
non-variadic calling convention of the functions.
The reality is that that xdr_string should not be cast to xdrproc_t and
xdr_wrapstring should be used instead so we do not need to support this
case. Instances of the former behavior are now extremely rare.
With this change we bring FreeBSD in line with gssrpc and the Linux
Kernel. Warnings about casts should now be correct and should be fixed.
Bump __FreeBSD_version as some software required adaptation if it is
declaring functions to cast to xdrproc_t. Update OpenZFS's workaround
of this historic mess accordingly.
Effort: CHERI upstreaming
Sponsored by: Innovate UK
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D54824
Similar to the same glibc function.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D54766
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
When a compiler with C23 or higher is detected, builtin bool, true,
and false are used to conform the C23 standard.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44664
Define _ALIGNBYTES using sizeof(void *) (no functional change on any
existing architecture) which will allow it to work with CHERI were we
must align things up to capability alignment.
In _ALIGN, replace integer manipulation which does not preserve pointer
provenance with a type and provenance preserving builtin. This requires
modest changes in code which assumes _ALIGN returns an integer, but
those are relatively rare.
Reviewed by: kib, markj
Effort: CHERI upstreaming
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D53947
Seems like a number of ports are *really* unhappy with this new
macro. These ports will have to be fixed and the patch reworked
to perhaps not affect C++ (see D54041). A general discussion on
how we expose new language features may also need to take place.
Reported by: many people
Approved by: markj (mentor)
This reverts commit b381d09802.
This new header complies with ISO/IEC 9899:2024 (C23).
Contrary to glibc, we do not provide inline definitions in
<stdbit.h> as we expect our system compiler to soon recognise
these as builtins anyway.
Relnotes: yes
MFC after: 1 month
Reviewed by: adrian
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D53657
unreachable() is a hint to the compiler that it is unreachable.
Add a new man page unreachable(3) to document this macro.
Reviewed by: imp
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53967
A type similar to char16 and char32_t, for compliance with C23.
The related type atomic_char8_t is added to stdatomic.h.
As char8_t is always unsigned char, I've skipped adding __char8_t.
This can be added, too, if desired.
Reviewed by: imp
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53952
This function is part of ISO/IEC 9899:2024 (C23) and was forgotten in D47856.
Reviewed by: imp
Approved by: markj (mentor)
See also: D47856
Fixes: 59677aecb6
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53951
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), [email protected]
Approved by: markj (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D53673
by removing the cast to _Bool. The _Bool type is not defined for C++,
and the specification from the gcc info doc states that the return
type of the __builtin_{add,sub,mul}_overflow() is bool already.
This is done instead of including stdbool.h to avoid namespace
pollution, since defining bool from stdckdint.h simingly is not
sanctioned by ISO/IEC 9899:2024.
PR: 290299
Reviewed by: des
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D53149
MD5 is used by libc/resolv to generate a random sequence id from a
current time stamp. Replace this convoluted mechanism with a call
to arc4random(). This permits us to entirely drop MD5 from libc,
simplifying the MD5 rework proposed in D45670.
Approved by: markj
Reviewed by: kevans, markj
See also: D45670
Event: EuroBSDcon 2025
Differential Revision: https://reviews.freebsd.org/D52784
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
Includes diff reduction to upstream version of this patch.
MFC after: 3 days
Sponsored by: Klara, Inc.
Reviewed by: philip
Differential Revision: https://reviews.freebsd.org/D39715
This function was never safe to use. We marked it deprecated in the
manual page in 2016, and it is marked obsolete in POSIX 2024. We
previously added a linker warning and annotated the prototype; now that
stable/15 has been branched, we can remove it from main.
Relnotes: yes
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D52474
For MIT Kerberos, MK_GSSAPI has no meaning: GSSAPI is a required part of
Kerberos and is always built if MK_KERBEROS is enabled. Backport this
behaviour to Heimdal so it works the same way.
While here, change Heimdal's libcom_err and compile_et to be selected by
MK_KERBEROS, not MK_KERBEROS_SUPPORT, since these are part of Kerberos
and third-party users might need it even if Kerberos support is disabled
in the base system. This means MK_KERBEROS_SUPPORT installs the same
files with both MIT and Heimdal.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D51859
Following the earlier removal of keyserv, none of this functionality
works since it requires keyserv.
Remove the relevant symbols from libc's Symbol.map. Leave compatibility
symbols for existing applications, but since the functions don't work
without keyserv, stub them out to return an error.
Remove some private symbols that were only used by keyserv; these don't
get compatibility symbols.
Remove the documentation for the old functions.
Remove rpc.ypupdated since it requires DES authentication.
Reviewed by: manu, des, emaste
Differential Revision: https://reviews.freebsd.org/D50442
lib/libgssapi is based on Heimdal. As on Linux systems, the MIT
libgssapi_krb5 replaces it. With both gssapi libraries and header files
installed results in broken buildworld (gssd) and ports that will not
build without modifications to support the MIT gssapi in an alternate
location.
73ed0c7992 removed the MIT GSSAPI headers from /usr/include. Apps using
MIT KRB5 gssapi functions and structures will fail to build without this
patch.
This patch includes a temporary patch to usr.sbin/gssd to allow it
to build with this patch. rmacklem@ has a patch for this and for
kgssapi that uses this patch to resolve kgssapi issues for NFS with
Kerberos.
This patch is an updated version of D51661 to allow it to build following
additional patchs to the tree.
This should have been implmented with 7e35117eb0.
Fixes: 7e35117eb0, 73ed0c7992
Differential Revision: https://reviews.freebsd.org/D51661
This function was never safe to use. We marked it deprecated in the
manual page in 2016, and it is marked obsolete in POSIX 2024. Add a
linker warning and annotate the prototype.
Sponsored by: Klara, Inc.
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D51681
This seems to fit the pattern better (e.g. fdopendir()).
I've added weak references to ease the transition, but since it's only
been a few days, we can remove them (and the ObsoleteFiles entries for
the manual pages) before we branch stable/15.
Fixes: deeebfdeca
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D50980
While here, clean up scandir() a bit and improve the documentation.
MFC after: never
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D50935
We only define SIG2STR_MAX with careful visibility, but define the
fortified version unconditionally. It needs to have the same visibility
both places.
Fixes: 3d12567133
Reviewed by: jrtc27, kevans
Sponsored by: Netflix
While the type of va_list and implementation of va_*() psuedo functions
varies (sometimes greatly) by architecture, they will always be defined
by the compiler in a consistant way that does not require machine
dependent handling.
MFC after: 1 week
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Rely in sys/_visible for visibility macros and use __buitin_va_list
instead of __va_list everywere we declare va_list.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Switch to sys/_visible.h for visibility macros.
Prefer __builtin_offsetof over __offset. sys/cdefs.h always defines
__offsetof to __builtin_offsetof so just use the latter to remove a
dependency on sys/cdefs.h. Realistically, we're never going to care
about a compiler that doesn't supply this builtin.
Add a somewhat questionable guard around the offsetof() definition
because the compiler no longer thinks it the same as a number of other
redundent definitions scattered around (e.g., in the openzfs codebase).
It is actually the same and those defintions likely shouldn't exist at
all, but it's easy to add a guard for now.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
These headers relied in __BEGIN_DECS/__END_DECLS being defined when
sys/_types.h was included, but there's not a requirement that this be
the case.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Konstantin Belousov