This header conforms to the C11 standard
Reference: ISO/IEC 9899:201x 7.15 Alignment <stdalign.h>
According to ISO/IEC 9899:201x (draft) 7.15 Alignment <stdalign.h> defines
four macros:
- alignas which expands to _Alignas
- alignof which expands to _Alignof
- __alignas_is_defined and __alignof_is_defined which both expand to 1
The _Alignas declaration appears as one of the type specifiers to modify
the alignment requirement of the object being declared.
The _Alignof operator is used to query the alignment requirement of its
operand type.
ISO/IEC N3242=11-0012 (C++1x) and ISO/IEC N3797 (C++1y) both note a header
<cstdalign> which defines only __alignas_is_defined and shall not define
the alignas macro. It misses the alignof case as it's probably based on an
older C1x draft, which defined only alignas. Assume that this is a bug in
the standard and treat alignof the same way as alignas in C++11.
Allow to define alignas and alignof in C++ prior the C++11 standard. It
might be broken but a nonstandard C++ compiler might support C11-like
_Alignas and _Alignof. Note that it's fatal for g++(1) v.5.4.
This header conforms to the C11 standard
Reference: ISO/IEC 9899:201x 7.23 _Noreturn <stdnoreturn.h>
According to ISO/IEC 9899:201x (draft) <stdnoreturn.> defines the
noreturn macro which expands to _Noreturn.
The _Noreturn keyword appears in a function declaration and specifies
that the function does not return by reaching the end of the function
body.
Design choices:
- don't implicitly break C++ code including this header with #error
C++11 offers [[noreturn]] which conflicts with C11 _Noreturn
- don't check for __STDC_VERSION__, everybody is free to reuse it with
a nonstandard compiler not conforming to C11 but supporting _Noreturn
gcc(1) and clang(1) support _Noreturn in -std=c99 and older standards
this follows <stdbool.h> choice for not checking for C99
- follow <stdbool.h> and declare the __noreturn_is_defined guard
- use a standard header guard (_STDNORETURN_H_), similar to <stdbool.h>
Reviewed by <pgoyette> and <joerg>
This is the user/application API and does not include the kernel
interface. Definitions shared with the kernel are found in
<sys/quota.h>.
Since I've been working on a local branch I have taken the liberty of
moving the latest-so-far version of <quota.h> to the front of the
patch queue. This loses (a small amount of) history but has the
advantage of avoiding unnecessary version bumps of libquota.so.
sys/stdarg.h and expect compiler to provide proper builtins, defaulting
to the GCC interface. lint still has a special fallback.
Reduce abuse of _BSD_VA_LIST_ by defining __va_list by default and
derive va_list as required by standards.
parse quota plists; as well as a getfsquota() function to retrieve quotas
for a single id from a single filesystem (whatever filesystem this is:
a local quota-enabled fs or NFS). This is build on functions getufsquota()
(for local filesystems with UFS-like quotas) and getnfsquota();
which are also available to userland programs.
move functions from quota2_subr.c to libquota or libprop as appropriate,
and ajust in-tree quota tools.
move some declarations from kernel headers to either sys/quota.h or
quota/quota.h as appropriate. ufs/ufs/quota.h still installed because
it's needed by other installed ufs headers.
ufs/ufs/quota1.h still installed as a quick&dirty way to get a code
using the old quotactl() to compile (just include ufs/ufs/quota1.h instead of
ufs/ufs/quota.h - old code won't compile without this change and this is
on purpose).
Discussed on tech-kern@ and tech-net@ (long thread, but not much about
libquota itself ...)
They implement a space efficent write-once database with fast access
path. Switch the services(5) database to use cdb. The size of the
database file decreases from 2.1MB disk space to 307KB. Access
performance is about the same if setservent(0) is used and about an
order of magnitude faster otherwise. services_mkdb defaults to the new
format, but can optionally create the old db(3) format as well for
statically linked legacy applications.
Most complex function implementations are from the "c9x-complex" library,
originating from the "cephes" math library, see
http://www.netlib.org/cephes/, from Stephen L. Moshier, incorporated and
redistributed with the NetBSD license by permission of the author.
Error behaviour and other boundary conditions (branch cuts)
need to be looked at.
For namespace sanity, I've done the rename/weak alias procedure to
most of the exported functions which are also used internally.
Didn't do so for sin/cos(f) yet because assembler implementations use
them directly, and renaming functions shared between the main libm
and the machine specific "overlay" might raise binary compatibility
issues.
(what other systems keep in libssp, we already have in libc) into libc
to match what other systems with FORTIFY_SOURCE do. Goodbye, libssp
dependency in libraries and executables. Discussed with christos and
mrg; Christos will merge the headers to get us the rest of the way to a
FORTIFY_SOURCE implementation that works as others' code expects.
Seems to be quite stable. Some work still left to do.
Please note, that syscalls are not yet MP-safe, because
of the file and vnode subsystems.
Reviewed by: <tech-kern>, <ad>
"/usr/include/machine/varargs.h") by a stub include file which will
emit an error if GCC 3.3 or newer is used and include "machine/varargs.h"
otherwise.
Based on a suggestion by Richard Earnshaw. This fixes PR toolchain/22888
by myself.
HAVE_GCC3. if this is set, we also set USE_TOOLS_TOOLCHAIN=no. change
the definition of the former to be restricted to whether tools/toolchain
is used or not.
future direction: nuke /usr/include/sys/sha1.h, it shouldn't be there as
we don't provide libkern to userland.
This mirrors the same change for md5.h made by itojun on 2000/12/11.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
to <sys/types.h> and <sys/stdint.h>.
* Add a new C99 <stdint.h> header, which provides integer types of
explicit width, related limits and integer constant macros.
* Extend <inttypes.h> to provide <stdint.h> definitions and format
macros for printf() and scanf().
* Add C99 strtoimax() and strtoumax() functions.
* Use the latter within scanf().
* Add C99 %j, %t and %z printf()/scanf() conversions for
intmax_t, pointer-type and size_t arguments.
kamil