The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The tendency in English, as prescribed in style guides like
Chicago MoS, is towards removing hyphens after prefixes
like "non-" etc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Edward reported a problem in the example code, where a variable
seems to be misnamed. Upon inspection, there seem to be a few
such instances, and this patch is my best guess at how things
should look.
Reported-by: Edward Welbourne <eddy@opera.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Starting in glibc 2.10, defining _XOPEN_SOURCE >= 700,
or _POSIX_C_SOURCE >= 200809 exposes the declarations of
these functions.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.8, one of _BSD_SOURCE, _SVID_SOURCE, or _GNU_SOURCE
must be defined to obtain these definitions.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The sentence mentions twice POSIX.1-2001.
I guess the second one should be POSIX.1-2008.
This should be checked in the standard.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* pthread_attr_setstacksize was cut&pasted.
* The stacksize argument can be compared to PTHREAD_STACK_MIN, not the
stackaddr address.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking at the man page, this is not a family of functions.
So "returns" is right, "functions" should be "function".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add ENOMEM error; improve EINVAL description. Also, make
RETURN VALUE section a little more accurate in its mention
of errno.
Reported-by: Georg Sauthoff <gsauthof@techfak.uni-bielefeld.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>