capabilities.7: Fix 2 version numbers under "Effect of user ID changes on capabilities"

Reported by Liu Jiaming <storypku@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
setenv.3: Clarify that setenv() returns success in the overwrite==0 case

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
proc.5: Document /proc/sys/kernel/ngroups_max

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
getgroups.2: Note that NGROUPS_MAX is defined in <limits.h>

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
getgroups.2: Clarify that sysconf(_SC_NGROUPS_MAX) is a run-time technique

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
getgroups.2: Document /proc/sys/kernel/ngroups_max

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fexecve.3: POSIX.1-2008 specifies fexecve()

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fexecve.3: Explain the use and rationale of fexecve()

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
stat.2: Update discussion of nanosecond timestamps

The existing text describes the timestamp fields as 'time_t'
and delegates discussion of nanosecond timestamps under NOTES.
Nanosecond timestamps have been around for a while now,
and are in POSIX.1-2008, so reverse the orientation of the
discussion, putting the nanosecond fields into DESCRIPTION
and detailing the historical situation under NOTES.

Reported-by: Yang Yang <yangyang.gnu@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
stat.2: Not filesystem support for nanosecond timestamps

Add some detail on which native filesystems do and don't
support nanosecond timestamps.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
stat.2: Cosmetic reworking of timestamp discussion in NOTES

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
execve.2: 'arg...' for interpreter scripts starts with argv[1]

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
futex.2: Fix link to Rusty's futex example library

When I asked to webmaster@kernel.org, Konstantin Ryabitsev
answered that the ".nl." is "an obsolete scheme and really
should be changed to just ftp.kernel.org".

Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
symlink.2: Give arguments of symlink() more meaningful names

Reported-by:  Fabrice Bauzac <libnoon@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
readlink.2: Fix typo in eror message in example program

Reported-by: Yuanhang Zheng <zhengyhn@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
flock.2: tfix

Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
malloc.3: Scale back promises of alignment

It's not true that the return value is suitably aligned for "any
variable"; for example, it's unsuitable for a variable like
  float *x __attribute__ ((__vector_size__ (32)));
which requires 32-byte alignment.  Types like this are defined in
<avxintrin.h>, and with 16-byte alignment in <emmintrin.h> and
<xmmintrin.h>, so the application programmer need not even know
that a vector_size attribute has been applied.

On an x86 architecture, a program that loads from or stores to a
pointer with this type derived from malloc can crash because GCC
generates an aligned load/store, like MOVDQA.

The C99 standard (TC3, as of N1256) does say the return value is
suitably aligned for "any type of object".  The C11 standard (as
of N1570) revises this to any type with "fundamental alignment",
which means an alignment "supported by the implementation in all
contexts", which I suppose tautologically includes aligning
malloc/realloc return values.

The actual behavior of current glibc malloc is to align to the
greater of 2 * sizeof(size_t) and __alignof__ (long double),
which may be one bit greater than this commit promises.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
ftok.3: ATTRIBUTES: Note function that is thread-safe

The function ftok() is thread safe.

Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
adjtime.3: ATTRIBUTES: Note function that is thread-safe

The function adjtime() is thread safe.

Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
alloca.3: ATTRIBUTES: Note function that is thread-safe

The function alloca() is thread safe.

Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>