See http://bugzilla.kernel.org/show_bug.cgi?id=13569
As noted by Andrey:
The purpose of the assert macro, defined in <assert.h>,
is to provide a tool to check for programming mistakes
or program logic errors. However, the assert macro must
never be used to perform checks for run time errors,
since, with the NDEBUG macro defined, expressions within
the assert macro invocations are not evaluated/checked
for, resulting in behavior that was not originally intended.
...
The pages affected in the core package are
execve(2)
pipe(2)
tee(2)
fmemopen(3)
mq_notify(3)
qsort(3)
Reported-by: Andrey Vihrov <vihrov@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The POSIX timers API is implemented (mostly) within the kernel,
so thse interfaces are system calls. Although there are as yet
no man pages, when they are added they should be in Section 2,
not 3. Therefore fix those pages that currently refer to these
interfaces as being in Section 3.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
POSIX.1-2001 says that the values returned by sysconf()
are constant for the life of the process.
But the fact that, since Linux 2.6.23, ARG_MAX is settable
via RLIMIT_STACK means _SC_ARG_MAX is no longer constant,
since it can change at each execve().
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Starting with Linux 2.6.23, the ARG_MAX limit became settable via
(1/4 of) RLIMIT_STACK. This broke ABI compatibility if RLIMIT_STACK
was set such that ARG_MAX was < 32 pages. Document the fact that
since 2.6.25 Linux imposes a floor on ARG_MAX, so that the old limit
of 32 pages is guaranteed.
For some background on the changes to ARG_MAX in kernels 2.6.23 and
2.6.25, see:
http://sourceware.org/bugzilla/show_bug.cgi?id=5786http://bugzilla.kernel.org/show_bug.cgi?id=10095http://thread.gmane.org/gmane.linux.kernel/646709/focus=648101,
checked into 2.6.25 as commit a64e715fc74b1a7dcc5944f848acc38b2c4d4ee2.
Also some reordering/rewording of the discussion of ARG_MAX.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Using a NULL envp does in fact seem to be portable (works
on Solaris and FreeBSD), but the Linux semantics for a NULL
argv certainly aren't consistent with other implementations.
See http://bugzilla.kernel.org/show_bug.cgi?id=8408.