endian.h: Define uint{16,32,64}_t

The Draft Posix Issue 8 standard requires that these be defined. Define
them in the usual way that lets multiple headers define them. Opted to
not just use #include

endian.h: Define uint{16,32,64}_t

The Draft Posix Issue 8 standard requires that these be defined. Define
them in the usual way that lets multiple headers define them. Opted to
not just use #include <stdint.h>, allowed by the draft, to be
conservative. Add notes about how we comply with Issue 8, and that we've
opted to define these only as macros, though the standard allows
functions, macros or both.

Sponsored by: Netflix

show more ...

sys/sys/_endian.h: typo (Compatiblity)

https://bugs.freebsd.org/269753

PR: 269753
Reported by: Igor Ostapenko
Approved by: doc, src (delphij, imp, zlei)

sys/sys/_endian.h: typo (Compatiblity)

https://bugs.freebsd.org/269753

PR: 269753
Reported by: Igor Ostapenko
Approved by: doc, src (delphij, imp, zlei)
Differential revision: https://reviews.freebsd.org/D38741

show more ...

_endian.h: Include sys/ctypes.h for visibility macros

BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN will be required by the
forthcoming POSIX Issue 8. In addition, they are provided in the BSD
compilatio

_endian.h: Include sys/ctypes.h for visibility macros

BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN will be required by the
forthcoming POSIX Issue 8. In addition, they are provided in the BSD
compilation environments. However, depending on the order includes
happend, sys/cdefs.h may or may not be included when endian.h is
included. Include it here so we can safely test __BSD_VISIBLE. Add
visibility when we're compiling in the future for issue 8, but since the
date number for issue 8 hasn't been fixed, use strictly greater than the
issue 7 date.of 200809.

This had the side effect of sometimes (in the traditional BSD
compliation environment)
#if BYTE_ORDER == LITTLE_ENDIAN
and
#if BYTE_ORDER == BIG_ENDIAN
both being true because none of these were defined. This fixes
that. It also fixes including it after <stdio.h> but not before.

PR: 269249
MFC After: 1d (build related)
Reviewed by: kib, emaste
Differential Revision: https://reviews.freebsd.org/D39176

Sponsored by: Netflix

show more ...

sys/_endian.h: Move powerpc workaround into _endian.h

Powerpc compilers often define _BIG_ENDIAN or _LITTLE_ENDIAN depending
on the byte order of the target. This interfers with the endian.h and
sys

sys/_endian.h: Move powerpc workaround into _endian.h

Powerpc compilers often define _BIG_ENDIAN or _LITTLE_ENDIAN depending
on the byte order of the target. This interfers with the endian.h and
sys/endian.h APIs which expect those two to be 4321 or 1234.
Unconditionally undefine these two before we define them to work around
this issue. By including endian.h, the programmer is saying they want
this API not the native one. This matches historic practice as well.

Fixes: e35448a901aa
Sponsored by: Netflix
Noticed by: powerpc, powerpc64 CI jobs

show more ...

byteswap.h: Add a glibc/linux compatible byteswap.h

For endian.h to work instead of sys/endian.h, some software needs
byteswap.h available. It must define {__,}byteswap_{16,32,64}.
Included sys/_end

byteswap.h: Add a glibc/linux compatible byteswap.h

For endian.h to work instead of sys/endian.h, some software needs
byteswap.h available. It must define {__,}byteswap_{16,32,64}.
Included sys/_endian.h to get an appropriate __byteswap16, etc
and defines the new macros in terms of them. Enhance _endian.h
to allow it to be included from here too.

Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D32051

show more ...

linux: For better compatibility, provide compatible endian.h

Add endian.h. This includes sys/endian.h and then adds extra defines
that glibc defines with double underscores for our
_{BIG,BYTE,LITTLE

linux: For better compatibility, provide compatible endian.h

Add endian.h. This includes sys/endian.h and then adds extra defines
that glibc defines with double underscores for our
_{BIG,BYTE,LITTLE,PDP}_ENDIAN macros. We also define __FLOAT_WORD_ORDER
to be the same as _BYTE_ENDIAN since FreeBSD doesn't currently define
this, and the default with glibc is exactly this for our platforms.
Move common parts of endian.h and sys/endian.h into sys/_endian.h
to limit namespace pollution from endian.h

All this gives us good compatibility with Linux. There may be one or two
upstreams that haven't integrated the patches I tried to send up.

There are some minor differences:
o The extra glibc macros are not defined. These are all
controlled with either __ at the start, or only defined
when glibc is being built. We also don't define macros
that are used internally in glibc that would pollute
the namespace.
o For complete compatibility, this change must also be
paired with providing a glibc-compatible byteswap.h.

Sponsored by: Netflix
Reviewed by: mhorne, markj, jhb
Differential Revision: https://reviews.freebsd.org/D31962

show more ...

Consolidate machine/endian.h definitions

This change serves two purposes.

First, we take advantage of the compiler provided endian definitions to
eliminate some long-standing duplication between th

Consolidate machine/endian.h definitions

This change serves two purposes.

First, we take advantage of the compiler provided endian definitions to
eliminate some long-standing duplication between the different versions
of this header. __BYTE_ORDER__ has been defined since GCC 4.6, so there
is no need to rely on platform defaults or e.g. __MIPSEB__ to determine
endianness. A new common sub-header is added, but there should be no
changes to the visibility of these definitions.

Second, this eliminates the hand-rolled __bswapNN() routines, again in
favor of the compiler builtins. This was done already for x86 in
e6ff6154d203. The benefit here is that we no longer have to maintain our
own implementations on each arch, and can instead rely on the compiler
to emit appropriate instructions or libcalls, as available. This should
result in equivalent or better code generation. Notably 32-bit arm will
start using the `rev` instruction for these routines, which is available
on armv6+.

PR: 236920
Reviewed by: arichardson, imp
Tested by: bdragon (BE powerpc)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D29012

show more ...