The Linux man page for ptsname_r, when describing the behaviour
in the error case, is
- not consistent with the future POSIX standard (POSIX Issue 8).
- not consistent with musl libc.
Find attached a patch to
- keep it consistent with what glibc does,
- make it consistent with musl libc,
- make it consistent with the future POSIX standard (POSIX
Issue 8).
Details:
glibc's implementation of ptsname_r, when it fails, returns the
error code as return value AND sets errno. See
https://sourceware.org/git/?p=glibc.git;a=blob;f=login/ptsname.chttps://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/ptsname.chttps://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ptsname.c
musl's implementation of ptsname_r, when it fails, returns the error code
but does NOT set errno. See
https://git.musl-libc.org/cgit/musl/tree/src/misc/pty.c
The proposal to add ptsname_r to POSIX, with text
"If successful, the ptsname_r( ) function shall return zero.
Otherwise, an error number shall be returned to indicate the
error."
has been accepted for inclusion in POSIX Issue 8.
http://austingroupbugs.net/view.php?id=508
Therefore a portable program should look at the return value from
ptsname_r, NOT the errno value. The current text in the man page
suggests to look at the errno value, which is wrong (because of
musl libc) and not future-proof (because of future POSIX).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Redundant because this is a Section 3 page, and the
text also describes the implementation in glibc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.26, posix_spawn (2) function accepts the
POSIX_SPAWN_SETSID flag. This flag has been accepted by POSIX and
should be added to the next major revision. The current support
can be enabled with _GNU_SOURCE.
Upstream commit in glibc.git:
daeb1fa2e1 [BZ 21340] add support for POSIX_SPAWN_SETSID
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The implementation of the fork() step in posix_spawn(2) relies on
either fork(2), vfork(2) or clone(2) depending on the version of
the glibc and the arguments passed to posix_spawn(2).
It is sometimes ambiguous whether, when we are mentioning
"fork(2)", we are referring to the fork() step or the actual
fork(2) syscall.
This patch hopefully avoids the ambiguity by replacing confusing
occurrences by "the xxx() step" where appropriate.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Added a few lines about POSIX_SPAWN_USEVFORK so that it appears
clearly that since glibc 2.24, the flag has no effect.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since glibc 2.24, the use of posix_spawn (2) makes an
unconditional call to clone(CLONE_VM | CLONE_VFORK ...) rather
than relying on fork (2) or vfork (2).
As a consequence, the statements regarding the use of the flag
POSIX_SPAWN_USEVFORK and how the function decides whether it
should use fork (2) or vfork (2) are obsolete since glibc 2.24.
This patch makes a distinction in the manual page between glibc
2.24 and older versions.
Upstream commit in glibc.git:
9ff72da471 posix: New Linux posix_spawn{p} implementation
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Signed-off-by: Olivier Gayot <olivier.gayot@sigexec.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A year cannot only begin with week number 53 of the previous year but
also with week number 52. Year 2011 is an example for this case, as
can be easily seen with GNU date:
$ date -d "jan 1 2011" "+%c %V %G"
Sat Jan 1 00:00:00 2011 52 2010
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Andrew Micallef <andrew.micallef@live.com.au>
Reported-by: Walter Harms <wharms@bfs.de>
Reviewed-by: Andrew Micallef <andrew.micallef@live.com.au>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* man3/strftime.3 (%C): Describe the meaning of %EC conversion
specification.
(%E): Mention the concept of "era" in description.
(%O): Mention that alternative format is related to numeric
representation.
(%y): Describe the meaning of %Ey conversion specification.
(%Y): Describe the meaning of %EY conversion specification.
(.SH DESCRIPTION): Mention that the behaviour of %E modifier is governed
by ERA locale element and provide ja_JP locale as an example.
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As it wasn't clear before where this kind of information can be
obtained from.
* man3/strftime.3 (%a, %A, %b, %B, %c, %p, %r, %x, %X): Add information
about the locale elements that can be used to retrieve the relevant
information using nl_langinfo() library call.
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In many cases, these don't improve readability, and (when stacked)
they sometimes have the side effect of sometimes forcing text
to be justified within a narrow column range.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
One might be tempted to think that realloc() always requests a new
allocation before moving the contents over (at least in the case
where the new size is bigger than the original). This is not the
case; for example, on my system the following program:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
void *x = malloc(15);
void *y = malloc(32);
printf("x = %p\n", x);
printf("y = %p\n", y);
printf("usable_size(x) = %lu\n", malloc_usable_size(x));
void *z = realloc(x, 24);
printf("z = %p\n", z);
return 0;
}
prints:
x = 0x1b3a010
y = 0x1b3a030
usable_size(x) = 24
z = 0x1b3a010
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Admittedly, the POSIX specification for exit() also uses octal.
However, 0xFF immediately indicates the lowest 8 bits to me
whereas I had to think a bit about the octal mask.
Cowritten-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From an email by Rich Felker:
It came to my attention while reviewing possible breakage with
move to 64-bit time_t that some applications are dereferencing
data in socket control messages (particularly SCM_TIMESTAMP*)
in-place as the message type, rather than memcpy'ing it to
appropriate storage. This necessarily does not work and is not
supportable if the message contains data with greater alignment
requirement than the header. In particular, on 32-bit archs,
cmsghdr has size 12 and alignment 4, but struct timeval and
timespec may have alignment requirement 8.
I found at least ptpd, socat, and ssmping doing this via Debian
Code Search:
https://sources.debian.org/src/ptpd/2.3.1-debian1-4/src/dep/net.c/?hl=1578#L1578https://sources.debian.org/src/socat/1.7.3.3-2/xio-socket.c/?hl=1839#L1839https://sources.debian.org/src/ssmping/0.9.1-3/ssmpngcl.c/?hl=307#L307
and I suspect there are a good deal more out there. On most archs
they won't break, or will visibly break with SIGBUS, but in theory
it's possible that they silently read wrong data and this might
happen on some older and more tiny-embedded-oriented archs.
I think it's clear to someone who understands alignment and who's
thought about it that applications just can't do this, but it
doesn't seem to be documented, and an example in cmsg(3) even
shows access to int payload via *(int *)CMSG_DATA(cmsg) (of course
int is safe because its alignment is <= header alignment, but this
is not mentioned).
Could we add text, and perhaps change the example, to indicate
that in general memcpy needs to be used to copy the payload
to/from a suitable object?
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch is a minor wording fix in getcwd.3 that changes "In the case getcwd()" to "In the case of getcwd()". This patch should apply cleanly to the master branch of the git repository.
Regards,
Mike Salvatore
From 3b68ad225dbaada2b1b55153dc57807b04531cd6 Mon Sep 17 00:00:00 2001
From: Mike Salvatore <mike.salvatore@canonical.com>
Date: Thu, 16 Jan 2020 16:08:08 -0500
Subject: [PATCH] getcwd.3: wfix
Signed-off-by: Mike Salvatore <mike.salvatore@canonical.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fixes: d8d701003 ("malloc.3: Since glibc 2.29, realloc() is exposed by
defining _DEFAULT_SOURCE")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The glibc implementation of getpt has actually never been setting
O_NOCTTY when opening /dev/ptmx or BSD ptys.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In a recent conversation with Mathieu Desnoyers I was reminded
that we haven't written up anything about how deferred
cancellation and asynchronous signal handlers interact. Mathieu
ran into some of this behaviour and I promised to improve the
documentation in this area to point out the potential pitfall.
Thoughts?
8< --- 8< --- 8<
In pthread_setcancelstate.3, pthreads.7, and signal-safety.7 we
describe that if you have an asynchronous signal nesting over a
deferred cancellation region that any cancellation point in the
signal handler may trigger a cancellation that will behave
as-if it was an asynchronous cancellation. This asynchronous
cancellation may have unexpected effects on the consistency of
the application. Therefore care should be taken with asynchronous
signals and deferred cancellation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add entries for the new cache geometry values of the auxiliary
vector that got included in the kernel.
Signed-off-by: Raphael Moreira Zinsly <rzinsly@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This requirement on the first digit with the %e format comes from
the ISO C standard. It ensures that all the digits in the output are
significant and forbids output with a precision less than requested.
Signed-off-by: Vincent Lefevre <vincent@vinc17.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The --export-dynamic linker option is not the only way that main's
global symbols may end up in the dynamic symbol table and thus be
used to satisfy symbol reference in a shared object. A symbol
may also be placed into the dynamic symbol table if ld(1)
notices a dependency in another object during the static link.
Verified by experiment; see previous commit.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text wrongly implied that symbol look up first
occurred in the object and then in main, and did not mention
whether dependencies of main where used for symbol resolution.
Verified by experiment:
$ cat prog.c
#define _GNU_SOURCE
#include <link.h>
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void /* A function defined in both main and lib_x1 */
prog_x1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
/* The following function is forced into prog's dynamic symbol table
because of the static link-time reference in lib_m1.so */
void /* A function defined in both main and lib_y1 */
prog_y1_exp(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
/* The following function is not forced into prog's dynamic symbol table */
void /* A function defined in both main and lib_y1 */
prog_y1_noexp(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
static int
callback(struct dl_phdr_info *info, size_t size, void *data)
{
printf("\tName = %s\n", info->dlpi_name);
return 0;
}
int
main(int argc, char *argv[])
{
void *xHandle, *yHandle;
void (*funcp)(void);
char *err;
xHandle = dlopen("./lib_x1.so", RTLD_NOW | RTLD_GLOBAL);
if (xHandle == NULL) {
fprintf(stderr, "dlopen: %s\n", dlerror());
exit(EXIT_FAILURE);
}
yHandle = dlopen("./lib_y1.so", RTLD_NOW | RTLD_GLOBAL);
if (yHandle == NULL) {
fprintf(stderr, "dlopen: %s\n", dlerror());
exit(EXIT_FAILURE);
}
/* Optionally display the link map() */
if (argc > 1) {
printf("Link map as shown from dl_iterate_phdr() callbacks:\n");
dl_iterate_phdr(callback, NULL);
printf("\n");
}
(void) dlerror(); /* Clear dlerror() */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic"
funcp = (void (*)(void)) dlsym(yHandle, "y1_enter");
#pragma GCC diagnostic pop
err = dlerror();
if (err != NULL) {
fprintf(stderr, "dlsym: %s", err);
exit(EXIT_FAILURE);
}
(*funcp)();
exit(EXIT_SUCCESS);
}
$ cat lib_m1.c
#include <stdio.h>
void /* A function defined in both lib_m1 and lib_y1 */
m1_y1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
#if 1
void
dummy(void)
{
extern void prog_y1_exp(void);
prog_y1_exp(); /* Forces prog_y1_exp into prog's dynamic symbol table,
so that it will be visible also to lib_y1.so */
}
#endif
$ cat lib_x1.c
#include <stdio.h>
void /* A function defined in both main and lib_x1 */
prog_x1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
void /* A function defined in both lib_x1 and lib_y1 */
x1_y1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
$ cat lib_y1.c
#include <stdio.h>
void /* A function defined in both lib_x1 and lib_y1 */
x1_y1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
void /* A function defined in both main and lib_y1 */
prog_y1_exp(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
void /* A function defined in both lib_m1 and lib_y1 */
m1_y1(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
void /* A function defined in both main and lib_y1 */
prog_y1_noexp(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
void
y1_enter(void)
{
extern void y2(void);
printf("Called %s\n\n", __func__);
prog_x1();
prog_y1_exp();
prog_y1_noexp();
x1_y1();
m1_y1();
y2();
}
$ cat lib_y2.c
#include <stdio.h>
void
y2(void)
{
printf("Called %s::%s\n", __FILE__, __func__);
}
$ cat Build.sh
#!/bin/sh
CFLAGS="-Wno-implicit-function-declaration -Wl,--no-as-needed"
cc $CFLAGS -g -fPIC -shared -o lib_x1.so lib_x1.c
cc $CFLAGS -g -fPIC -shared -o lib_y2.so lib_y2.c
cc $CFLAGS -g -fPIC -shared -o lib_y1.so lib_y1.c ./lib_y2.so
cc $CFLAGS -g -fPIC -shared -o lib_m1.so lib_m1.c
#ED="-Wl,--export-dynamic"
cc $CFLAGS $ED -Wl,--rpath,$PWD -o prog prog.c -ldl lib_m1.so
$ sh Build.sh
$ ./prog x
Link map as shown from dl_iterate_phdr() callbacks:
Name =
Name = linux-vdso.so.1
Name = /lib64/libdl.so.2
Name = /home/mtk/tlpi/code/shlibs/dlopen_sym_res_expt/lib_m1.so
Name = /lib64/libc.so.6
Name = /lib64/ld-linux-x86-64.so.2
Name = ./lib_x1.so
Name = ./lib_y1.so
Name = ./lib_y2.so
Called y1_enter
Called lib_x1.c::prog_x1
Called prog.c::prog_y1_exp
Called lib_y1.c::prog_y1_noexp
Called lib_x1.c::x1_y1
Called lib_m1.c::m1_y1
Called lib_y2.c::y2
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
My earlier commit was in error:
commit 4a1af09bd1
Author: Michael Kerrisk <mtk.manpages@gmail.com>
Date: Sat Mar 14 21:40:35 2015 +0100
dlopen.3: Amend error in description of dlclose() behavior
-If the reference count drops to zero and no other loaded libraries use
-symbols in it, then the dynamic library is unloaded.
+If the reference count drops to zero,
+then the dynamic library is unloaded.
I doubted the removed text, because it provide little clue about
the scenario. The POSIX dlclose(3) specification actually details
the scenario sufficiently:
Although a dlclose() operation is not required to remove
any functions or data objects from the address space,
neither is an implementation prohibited from doing so.
The only restriction on such a removal is that no func‐
tion nor data object shall be removed to which references
have been relocated, until or unless all such references
are removed. For instance, an executable object file that
had been loaded with a dlopen() operation specifying the
RTLD_GLOBAL flag might provide a target for dynamic relo‐
cations performed in the processing of other relocatable
objects—in such environments, an application may assume
that no relocation, once made, shall be undone or remade
unless the executable object file containing the relo‐
cated object has itself been removed.
Verified by experiment:
$ cat openlibs.c # Test program
int
main(int argc, char *argv[])
{
void *libHandle[MAX_LIBS];
int lcnt;
if (argc < 2) {
fprintf(stderr, "Usage: %s lib-path...\n", argv[0]);
exit(EXIT_FAILURE);
}
lcnt = 0;
for (int j = 1; j < argc; j++) {
if (argv[j][0] != '-') {
if (lcnt >= MAX_LIBS) {
fprintf(stderr, "Too many libraries (limit: %d)\n", MAX_LIBS);
exit(EXIT_FAILURE);
}
printf("[%d] Opening %s\n", lcnt, argv[j]);
libHandle[lcnt] = dlopen(argv[j], RTLD_NOW | RTLD_GLOBAL);
if (libHandle[lcnt] == NULL) {
fprintf(stderr, "dlopen: %s\n", dlerror());
exit(EXIT_FAILURE);
}
lcnt++;
} else { /* "-N" closes the Nth handle */
int i = atoi(&argv[j][1]);
printf("Closing handle %d\n", i);
dlclose(libHandle[i]);
}
sleep(1);
printf("\n");
}
printf("Program about to exit\n");
exit(EXIT_SUCCESS);
}
$ cat lib_x1.c
void x1_func(void) { printf("Hello world\n"); }
__attribute__((constructor)) void x1_cstor(void)
{ printf("Called %s\n", __FUNCTION__); }
__attribute__((destructor)) void x1_dstor(void)
{ printf("Called %s\n", __FUNCTION__); }
$ cat lib_y1.c
void y1_func(void) { printf("Hello world\n"); }
__attribute__((constructor)) void y1_cstor(void)
{ printf("Called %s\n", __FUNCTION__); }
__attribute__((destructor)) void y1_dstor(void)
{ printf("Called %s\n", __FUNCTION__); }
static void testref(void) {
/* The following reference, to a symbol in lib_x1.so shows that
RTLD_GLOBAL may pin a library when it might otherwise have been
released with dlclose() */
extern void x1_func(void);
x1_func();
}
$ cc -shared -fPIC -o lib_x1.so lib_x1.c
$ cc -shared -fPIC -o lib_y1.so lib_y1.c
$ cc -o openlibs openlibs.c -ldl
$ LD_LIBRARY_PATH=. ./openlibs lib_x1.so lib_y1.so -0 -1
[0] Opening lib_x1.so
Called x1_cstor
[1] Opening lib_y1.so
Called y1_cstor
Closing handle 0
Closing handle 1
Called y1_dstor
Called x1_dstor
Program about to exit
<end program output>
Note that x1_dstor was called only when handle 1 (lib_y1.so) was closed.
But, if we edit lib_y1 to remove the reference to x1_func(), things are
different:
$ cat lib_y1.c # After editing
void y1_func(void) { printf("Hello world\n"); }
__attribute__((constructor)) void y1_cstor(void)
{ printf("Called %s\n", __FUNCTION__); }
__attribute__((destructor)) void y1_dstor(void)
{ printf("Called %s\n", __FUNCTION__); }
static void testref(void) {
// extern void x1_func(void);
// x1_func();
}
$ cc -shared -fPIC -o lib_y1.so lib_y1.c
$ LD_LIBRARY_PATH=. ./openlibs lib_x1.so lib_y1.so -0 -1
[0] Opening lib_x1.so
Called x1_cstor
[1] Opening lib_y1.so
Called y1_cstor
Closing handle 0
Called x1_dstor
Closing handle 1
Called y1_dstor
Program about to exit
<end program output>
This time, x1_dstor was called when handle 0 (lib_x1.so) was closed.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's a program for doing experiments:
/* on_expt_scope_expt.c
(C) Michael Kerrisk, 2019, Licensed GNU GPLv2+
*/
char *tos;
static void
exitFunc(int status, void *p)
{
int efloc;
int *xp = (int *) p;
printf("====== Entered exit handler\n");
printf("&efloc = %p (0x%llx)\n",
(void *) &efloc, (long long) (tos - (char *) &efloc));
printf("xp = %p (value: %d)\n", (void *) xp, *xp);
if (*xp != INIT_VALUE)
printf("It looks like the variable passed to the exit handler "
"has gone out of scope\n");
/* Produce a core dump, which we can examine with GDB to look at the
frames on the stack, if desired */
printf("===\n");
printf("About to abort\n");
abort();
}
static void
recur(int lev, int *xp)
{
int rloc;
int big[65536-12]; /* 12*4 == 48 other bytes allocated on
this stack frame */
tos = (char *) &rloc;
big[0] = lev;
big[0]++;
printf("&rloc = %p (%d) (%d)\n", (void *) &rloc, lev, *xp);
if (lev > 1)
recur(lev - 1, xp);
else {
printf("exit() from recur()\n");
exit(EXIT_SUCCESS);
}
}
int
main(int argc, char *argv[])
{
int lev;
int *xp;
int xx;
if (argc < 2) {
fprintf(stderr, "Usage: %s {s|h} [how]\n", argv[0]);
fprintf(stderr, "\ts => exitFunc() arg is in main() stack\n");
fprintf(stderr, "\th => exitFunc() arg is allocated on heapn");
fprintf(stderr, "\tIf 'how' is not present, then return from main()\n");
fprintf(stderr, "\tIf 'how' is 0, then exit() from main()\n");
fprintf(stderr, "\tIf 'how' is > 0, then make 'how' recursive "
"function calls, and then exit()\n");
exit(EXIT_FAILURE);
}
tos = (char *) &xp;
if (argv[1][0] == 'h') {
xp = malloc(sizeof(int));
if (xp == NULL) {
perror("malloc");
exit(EXIT_FAILURE);
}
printf("Argument for exitFunc() is allocated on heap\n");
} else {
xp = &xx;
printf("Argument for exitFunc() is allocated on stack in main()\n");
}
*xp = INIT_VALUE;
printf("xp = %p (value: %d)\n", (void *) xp, *xp);
printf("===\n");
on_exit(exitFunc, xp);
if (argc == 2) {
printf("return from main\n");
return 0;
}
lev = atoi(argv[2]);
if (lev < 1) {
printf("Calling exit() from main\n");
exit(EXIT_SUCCESS);
} else {
recur(lev, xp);
}
}
Reported-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I've found the exec man page quite difficult to read when trying
to find the behavior for a specific function. Since the names of
the functions are inline and the order of the descriptions isn't
clear, it's hard to find which paragraphs apply to each function.
I thought it would be much easier to read if the grouping based on
letters is stated.
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>
Unlike strerror_r(), strerror_l() doesn't take buffer length as an
argument.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk