The const specifier is not part of the prototype (it only applies to the
implementation), so showing it here confuses the reader.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
stdarg.h is now 30 years old, and gcc long ago (2004) ceased to
implement <varargs.h>. There seems little value in keeping this
text.
See https://bugzilla.kernel.org/show_bug.cgi?id=202907
Reported-by: Vincent Lefevre <vincent@vinc17.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The BUGS section already explains why you need to be cautious
about using mallinfo, but given the number of bug reports we see
on Android, it seems not many people are reading that far. Call it
out up front.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.8, commit 68631c8eb92, the malloc_trim function has
iterated over all arenas and free'd back to the OS all page runs
that were free. This allows an application to call malloc_trim to
consolidate fragmented chunks and free back any pages it can to
potentially reduce RSS usage.
This correctness of the man page was recently brought to light by
an article [1] where Ruby developers discovered that malloc_trim
did not behave as the man page indicated.
This change makes it clear that the intent of malloc_trim is to
trim all space that is no longer needed, and any restrictions are
implementation details. In the notes we highlight the change in
behaviour for post glibc 2.8 and pre glibc 2.8.
[1] https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html#a-magic-trick-trimming
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Where is the initial read position for an "a+" stream?
POSIX leaves this unspecified. Most BSD man pages are silent, and MacOS
has the ambiguous "The stream is positioned at the end of the file", not
differentiating between reads and writes other than to say that fseek(3)
does not affect writes. glibc's documentation explicitly specifies that
the initial read position is the beginning of the file.
My new wording is based on the BSD implementations, so you may prefer
to replace the non-glibc section with "unspecified", or indeed remove
all claims about the initial read position.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Egmont suggested adding this, because the string "..." appears
at several other points in the page, but just to indicate that
some text is omitted from example code.
Reported-by: Egmont Koblinger <egmont@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The removed text long ago ceased to be accurate. Nowadays, the
dispatch table is autogenerated when building the kernel (via
the kernel makefile, arch/x86/entry/syscalls/Makefile).
Reported-by: Andreas Korb <andreas.d.korb@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Rewrite for improved clarity and defer to setfsuid(2) for the
rationale of the fsGID rather than repeating the same details
in this page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The current text reads somewhat clumsily. Rewrite it to introduce
the eUID and fsUID in parallel, and more clearly hint at the the
historical rationale for the fsUID, which is detailed lower in
the page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The section "Example Programs ..." was renamed to "Example programs ..."
(with lowercase p) in c634028ab5, but the reference was not
updated.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk