A limit can be defined by other than POSIX
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add note about length modifiers and conversions to [u]intmax_t,
and add a corresponding example.
Reported-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note: There are a few members of this structure that are
not required by POSIX (XSI extensions, and such).
I simply chose to not document them at all.
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Various ports that had their own indigenous system calls have
been discontinued. Remove those system calls (none of which had
manual pages!) to a separate part of the page, to avoid
cluttering the main list of system calls.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some of the links removed in commit 247c654385 should
have been kept, because in some cases there are real system
calls whose wrapper functions are documented in Section 3.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
SO_PEERSEC was introduced for AF_UNIX stream sockets connected via
connect(2) in Linux 2.6.2 [1] and later augmented to support
AF_UNIX stream and datagram sockets created via socketpair(2) in
Linux 4.18 [2]. Document SO_PEERSEC in the socket.7 and unix.7
man pages following the example of the existing SO_PEERCRED
descriptions. SO_PEERSEC is also supported on AF_INET sockets
when using labeled IPSEC or NetLabel but defer adding a
description of that support to a separate patch.
The module-independent description of the security context
returned by SO_PEERSEC is from Simon McVittie.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=da6e57a2e6bd7939f610d957afacaf6a131e75ed
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b811db2cb2aabc910e53d34ebb95a15997c33e7
Reviewed-by: Serge Hallyn <serge@hallyn.com>
Cowritten-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The initial version documents sigval, ssize_t, suseconds_t,
time_t, timer_t, timespec, and timeval.
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[mtk: the coding style used in the example could lead people to
inject memory leaks in their code if they cut/paste/modify the
code to replace "exit" paths with "return" paths from a library
function.]
[Marko, from the mail thread discussing this patch:]
You are right about terminating the process. However, people copy
that example and put the code in a function changing "exit" to
"return". There are a bunch of examples like that here
https://beej.us/guide/bgnet/html/#poll, for instance. That error
bothered me when reading the network programming guide
https://beej.us/guide/bgnet/html/. Than I looked for information
elsewhere:
https://stackoverflow.com/questions/6712740/valgrind-reporting-that-getaddrinfo-is-leaking-memoryhttps://stackoverflow.com/questions/15690303/server-client-sockets-freeaddrinfo3-placement
And finally, I checked manual pages and saw where these errors
come from.
When you change that to a function and return without doing
freeaddrinfo, that is a memory leak. I believe an example should
show good programming practices. Relying on exiting and clearing
the memory in that case is not such a case. In my opinion, these
examples lead people to make mistakes in their programs.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>