C89 is obsolete, and programs should target newer standards. If someone
needs information about is, the Standard itself is a better resource.
Let's move forward, so readers get the intended notice that C89 is not a
useful version of C.
scanf.3, sscanf.3, vsscanf.3: Split the page, one for strings and one for FILEs
From these functions, the ones that read from a FILE* are very difficult
--if not impossible-- to use correctly. Let's split the page into two,
so that we give the impression that sscanf(3) is the first class
citizen, and the others are just historic artifacts that are kept for
backwards-compatibility reasons.
FILE* variants are now in a page which clearly tells the reader to look
for other ways to read input.
Apparently the original author(s) of this table did not know how to
start a table entry in the first column of a tbl(1) table with a dot.
(If you try, the *roff formatter will interpret it as a control line,
and try to invoke a request or call a macro.)
Start every row of the table with the *roff dummy character `\&` instead
of leading space. Not only is this more idiomatic, but it recovers some
of the line length for content.
This patch does not attempt to correct any errors in the table contents,
nor bring it up to date from its year 2000 vintage.
The extension of the page length is workaround for
<https://savannah.gnu.org/bugs/?63449>, which is a very old groff bug,
possibily dating back to groff 1.00 or beyond. It is fixed in groff
Git. But waiting for a groff release is not necessary; man-db man(1)
nowadays conceals diagnostic messages from the formatter and output
drivers.
string_copying.7: Add page to document all string-copying functions
This is an opportunity to use consistent language across the
documentation for all string-copying functions.
It is also easier to show the similarities and differences between all
of the functions, so that a reader can use this page to know which
function is needed for a given task.
Alternative functions not provided by libc have been given in the same
page, with reference implementations.
Cc: Martin Sebor <msebor@redhat.com> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Douglas McIlroy <douglas.mcilroy@dartmouth.edu> Cc: Jakub Wilk <jwilk@jwilk.net> Cc: Serge Hallyn <serge@hallyn.com> Cc: Iker Pedrosa <ipedrosa@redhat.com> Cc: Andrew Pinski <pinskia@gmail.com> Cc: Stefan Puiu <stefan.puiu@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
INSTALL, Makefile, cmd.mk, lint-man.mk: Lint about '\" t' comment for tbl(1)
This is to make sure that we have correct \" t comments in the pages,
which are necessary for the Debian package checker:
On 8/19/22 22:21, Jakub Wilk wrote:
> * Michael Kerrisk <mtk.manpages@gmail.com>, 2020-07-24 12:13:
>> For 15 years or at least, I've not paid any attention to adding the
>> 't' comments when I added tables to pages, and I do recall anyone
>> reporting ill effects. So, I'm inclined to apply Mike's patch, but
>> will hold off a moment, in case there's other feedback.
>
> I'm a bit late, but...
>
> Lintian, the Debian package checker, sets the MANROFFSEQ environment
> variable to empty string as a speed optimization. This turns off
> loading preprocessors that weren't explicitly declared in the source.
> The lack of '\" comments can cause false positives (and maybe also
> false negatives?) in Lintian.
>
> The use of $MANROFFSEQ for Lintian was proposed here:
> https://bugs.debian.org/677874
>
> Beware that the man(1) man page does not correctly explain what
> $MANROFFSEQ does: <https://bugs.debian.org/971009>
Also update the dependencies list, since now we also need head(1) and
tail(1) for linting man(7) source.
Link: <https://lore.kernel.org/linux-man/07a7d4e7-79a6-b2c3-6892-1e39a0679f27@gmail.com/T/#mcf36c8a387fd5ff4f800dc220e3dbdd229b556bd> Reported-by: Jakub Wilk <jwilk@jwilk.net> Cc: Mike Frysinger <vapier@gentoo.org> Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Stefan Puiu <stefan.puiu@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Amir Goldstein [Tue, 13 Dec 2022 12:08:34 +0000 (14:08 +0200)]
copy_file_range.2: Fix wrong kernel version information
commit d7ba612d0 ("copy_file_range.2: Update cross-filesystem support
for 5.12") prematurely documented kernel 5.12 as the version that
changes the cross-fs copy_file_range() behavior, but that behavior
change was only merged in kernel version 5.19.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Ian Abbott [Thu, 8 Dec 2022 12:34:54 +0000 (12:34 +0000)]
scanf.3: Do not mention the ERANGE error
The `scanf()` function does not intentionally set `errno` to `ERANGE`.
That is just a side effect of the code that it uses to perform
conversions. It also does not work as reliably as indicated in the
'man' page when the target integer type is narrower than `long`.
Typically (at least in glibc) for target integer types narrower than
`long`, the number has to exceed the range of `long` (for signed
conversions) or `unsigned long` (for unsigned conversions) for `errno`
to be set to `ERANGE`.
Documenting `ERANGE` in the ERRORS section kind of implies that
`scanf()` should return `EOF` when an integer overflow is encountered,
which it doesn't (and doing so would violate the C standard).
Just remove any mention of the `ERANGE` error to avoid confusion.
Fixes: 646af540e467 ("Add an ERRORS section documenting at least some of the errors that may occur for scanf().")
Link: <https://lore.kernel.org/linux-man/5af4f708-337f-fddf-9a2d-e0e4602d3a72@mev.co.uk/T/#m900a1b1741afefab008a69e6b76919cd94aa81ef> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Zack Weinberg <zack@owlfolio.org> Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Use of numeric conversion specifiers can produce Undefined Behvaior
under conditions that the program doesn't control; therefore, there's no
way to use them safely.
Tycho Andersen [Mon, 28 Nov 2022 20:58:37 +0000 (13:58 -0700)]
socket.7: be explicit that connect(2) respects SO_*TIMEO
Our group recently had some confusion around this. Although f327722042df
("socket.7: Explain effect of SO_SNDTIMEO for connect()") adds a mention of
connect(2), the wording around "Timeouts only have effect for system
calls that perform socket I/O" is slightly confusing: is connect(2) I/O?.
Let's just add connect(2) to the list of things that time out explicitly to
avoid any confusion.
strncat.3: Overrunning the dest buffer is not that bad
With the right function call, that is, one that always copies the same
amount of bytes, and is so simple that can be inlined, the behavior
will be consistent enough to be warned by the compiler in most cases of
overrun, and crash quite consistently in the remaining.
Prefer simplicity over correctness, so suggest the simpler ustr2stp().
After some investigation, I found a case where this function is useful:
Concatenating an unterminated string into a string. It's not an ideal
API for that, but there's no other API that does it.
The closest thing, and something that some projects use instead of
strncat(3), is calling mempcpy(3) directly. However mempcpy(3) isn't
ideal either (it's faster; just that). It even requires a multiline
pattern to use correctly, which is a source of bugs.
So, suggest using a custom alternative that needs to be defined by the
programmer, which handles all the subtle details much better than any
of the conventional functions: ustr2stpe().
I had a mistake when adding VLA syntax to this prototype. From this
fixed prototype, it's visible how broken the design for this function
is. Next move is to kill this function.
Refer consistently to software versions. In most cases, it is done as
<software> <version>. In the case of Linux and glibc, use the project
name, instead of other terms such as 'kernel' or 'library'.
I found the uses of inconsistent language with the following:
projects / thirdparty / man-pages.git / log
