This helps write more readable code, separating variable declarations
from code. In some cases, when initializing structs, or declaring some
VLAs, we can't follow the rule, so don't make it an error.
Jan Engelhardt [Sun, 22 Jan 2023 11:20:34 +0000 (12:20 +0100)]
socket.7: tfix
The .TP macro is followed by exactly one line of definition, and then
multiple lines of flowed explanatory text. When flowed, the lack of
periods is apparent in sentences.
Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Promote a parenthetical to primary discussion. 64-bit systems are the
norm nowadays.
* Perform a Kemper notectomy. That is, stop saying "note that"
followed by some declarative statement. This trope is all over Unix
documentation and I even see it in ISO standards. The latter doesn't
serve to recommend it; as Dave Kemper has pointed out, everything we
put in technical documentation should be worthy of note unless placed
in a footnote, marked as "unnecessary on a first reading", or similar.
It is the exception, not the rule. If you feel the need to say "note
that", consider what adjacent material you shouldn't be saying at all.
* Say "symbolic link" instead of "symlink".
* When one sentence explains the previous, use a semicolon.
* Place the modifier "only" more carefully.
* Recast option descriptions to be in the imperative mood.
* Recast file descriptions to use the paragraph tag as the subject of
the first sentence.
Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Set page topic in lowercase.
* Rewrite synopses to use groff man(7) `SY`/`YS` extension macros.
* Rewrite synopses to use man(7) font macros instead of *roff font
selection escape sequences.
* In synopses, set ellipses as separate "operands" to better suggest
argument separation by white space.
* In synopses, prevent breaks within option brackets.
* Typeset ellipses more attractively on troff devices.
* Rewrite option list to use man(7) font macros instead of *roff font
selection escape sequences.
* Use groff man(7) `TQ` extension macro to include multiple tags for
options with long synonyms instead of comma notation.
* Set literals used as arguments to `-c` option in bold, not italics.
Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
* Drop stale FIXME annotation regarding commit ID for `-i` option.
* Drop redundant `PD` macro calls.
* Break input lines after commas.
* Set multi-word parentheticals on their own input lines.
* Break input lines at phrase boundaries more often.
* Protect literals from automatic hyphenation with `\%` escape sequence.
Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Not counting function names and cross references to the symlink(7) page,
"symbolic link" is preferred to "symlink" in existing pages by a ratio
of about 380 to the handful in this page.
Signed-off-by: G. Branden Robinson <g.branden.robinson@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
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().
projects / thirdparty / man-pages.git / log
