Ian Rogers [Fri, 6 Dec 2024 07:38:25 +0000 (23:38 -0800)]
proc_pid_fdinfo.5: Reduce indent for most of the page
When /proc/pid/fdinfo was part of proc.5 man page the indentation made
sense. As a standalone man page the indentation doesn't need to be so
far over to the right. Remove the initial tagged pragraph, move the
"since Linux 2.6.22" to a new HISTORY subsection.
Lorenzo Stoakes [Thu, 5 Dec 2024 10:41:25 +0000 (10:41 +0000)]
madvise.2: Add description of MADV_GUARD_INSTALL, MADV_GUARD_REMOVE
Lightweight guard region support has been added to Linux 6.13, which
adds MADV_GUARD_INSTALL and MADV_GUARD_REMOVE flags to the madvise()
system call. Therefore, update the manpage for madvise() and describe
these operations.
This diagnostic is useful for preventing unsafe macros, but other linter programs
provide a smaller rate of false positives, so let's turn this one off.
Yuanchu Xie [Wed, 20 Nov 2024 04:52:14 +0000 (20:52 -0800)]
posix_fadvise.2: POSIX_FADV_NOREUSE now supported.
POSIX_FADV_NOREUSE is now supported in Linux. Update text regarding
former no op behavior. Indicate the readahead policy and treatment of
file pages read with this flag.
mount_namespaces.7: Use correctly the terms "mount" and "mount point"
On Sun, Nov 17, 2024 at 16:12:24 +0100, Michael Kerrisk wrote:
>
> A "mount" is a tuple consisting of:
> * a mount ID
> * a source (e.g., a device)
> * a target or "mount point" (i.e. a path name)
> * the ID of the parent of this mount
> * other stuff (e.g., options)
Reported-by: Helge Kreutzmann <debian@helgefjell.de> Cc: Jakub Wilk <jwilk@jwilk.net> Acked-by: "Michael T. Kerrisk" <mtk.manpages@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Use 'length' for the lenght of a string.
Use 'n' for the number of elements.
Use 'size' for the number of bytes. (And in wide-character string
functions, 'size' also refers to the number of wide characters.)
The change is quite large, and I might have made some mistakes.
But overall, this should improve consistency in use of these terms.
Ken Pizzini [Fri, 15 Nov 2024 22:11:04 +0000 (14:11 -0800)]
printf.3: wfix
Improve description of %a format.
The description of the %a/%A specifiers in the printf(3) man page
could stand some improvement. In particular, it is not clear from the
current document what base is used for the "p±d" part of the format.
It can be inferred from the nature of %a that the base should be a power
of two. And it can be further inferred from the nature of hexadecimal
floating-point literals in C (as specified by C99 and later) that the
base must exactly be the number two, but it would be helpful for the
printf(3) man page to state this explicitly. My first expectation when
reading the man page was that the exponent would be taken in base 16;
after experimentation my second thought was that it would be base
FLT_RADIX (which is 2 on IEEE 754 floating-point systems, but 16 on
S/390). Only by going back to the standard [1] could I determine that
the exponent in p-notation must always be taken from a base of 2.
Link: [1] POSIX.1-2024 <https://pubs.opengroup.org/onlinepubs/9799919799/functions/printf.html> Cc: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Ken Pizzini <ken@gnu.org>
Message-ID: <b932f13642502e063ef139d57b8f3c496023bf4a.1731707666.git.ken@gnu.org> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Ken Pizzini [Fri, 15 Nov 2024 08:23:05 +0000 (00:23 -0800)]
printf.3: wfix
Improve terminology in %a description
The term "decimal point" does not technically apply when using bases
other than 10; the more generic term is "radix point". Update the
description of the a/A conversion specifier (i.e., for hexadecimal
floating point output) in printf(3) to use this terminology.
I do note that POSIX.1-2024 [1] does use the term "decimal-point
character" here, but I still maintain that using "radix point" is a
better term for that object in the %a description. (Confusingly, POSIX
does refer to "radix character" in the descriptions of %f and %e, where
reference to "decimal" instead of "radix" would actually make sense.)
Amir Goldstein [Tue, 5 Nov 2024 14:49:39 +0000 (15:49 +0100)]
fanotify_mark.2, fanotify.7: Update documentation of fanotify w.r.t fsid
Clarify the conditions for getting the -EXDEV and -ENODEV errors.
Signed-off-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz>
Message-ID: <20241105144939.181820-1-amir73il@gmail.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
scripts/bash_aliases: man_gitstaged(): Trim the dirname(1) only for files within man/
I changed the behavior at some point to trim the dirname(1) for every
file. However, that was mainly due to the inconvenience of not having a
man/ directory. Also, I haven't been consistent with that behavior, and
have been manually adding back the dirname(1), so let's bring back the
old behavior --which is BTW still what the comment says it does--.
===
In src/bin/mansect line 23:
-e '(?s)^\.SH ('"$s"')$(?:(?!^\.(lf 1|TH|SH) ).)*';
^-- SC2250 (style): Prefer putting braces around variable references even when not strictly required.
===
This triggers false positives with trivial PCRE2 regexes.
===
In src/bin/mansect line 23:
-e '(?s)^\.SH ('"$s"')$(?:(?!^\.(lf 1|TH|SH) ).)*';
^----------------------------^ SC2016 (info): Expressions don't expand in single quotes, use double quotes for that.
===
We don't want to support arbitrary manual-page file names.
===
In src/bin/mansect line 17:
find -H "$@" -not -type d \
^-----------------------^ SC2038 (warning): Use -print0/-0 or -exec + to allow for non-alphanumeric filenames.
===
src/bin/mansect, mansect.1: Add program and its manual page
Preprocess with preconv(1). This doesn't process the pages in a
significant way, and has the benefit that it writes the name of the
pages in the output.
Vincent Lefevre [Tue, 24 Sep 2024 11:54:46 +0000 (13:54 +0200)]
signal.7: Better description for SIGFPE
SIGFPE has comment "Floating-point exception", which corresponds to
the FPE acronym. But this is misleading as this signal may also be
generated by an integer division by 0.
Change it to "Erroneous arithmetic operation" from POSIX.
Note: the GNU C Library manual says "fatal arithmetic error".
Levi Zim [Fri, 27 Sep 2024 06:52:29 +0000 (14:52 +0800)]
dup.2: ERRORS: Add ENOMEM
dup2(2) could return ENOMEM under extreme condition. For example, when
sysctl fs.nr_open=2147483584, and RLIMIT_NOFILE is also 2147483584.
The following program fails with ENOMEM:
int
main(void)
{
if (dup2(0, 2000000000) == -1)
err(1, "dup2");
return 0;
}
This ENOMEM comes from an allocation error here:
<https://elixir.bootlin.com/linux/v6.1/source/mm/util.c#L596>
bind.2: ERRORS: Document possible errors from protocol
When looking through the errors of socket(2) I noticed that it specifies
the selected underlying protocol may extend the potential errors
returned. For example, using AF_PACKET and SOCK_RAW can return EPERM if
the user does not have CAP_NET_RAW or uid 0 (this is all fully
documented).
However, AF_PACKET and SOCK_RAW extend the potential errors returned
from bind(2) as well. For example, calling bind(2) with an invalid
sll_ifindex set on the sock_addr passed in will return ENODEV.
While this possibility is documented in the raw(7) manual page, the
bind(2) manual page does not mention that its potential set of errors
can be extended by the underlying protocol. This patch simply
duplicates the relevant language from the socket(2) manual page to the
bind(2) manual page.
It is possible further extensions for send(2), recv(2), setsockopt(2),
etc. are also undocumented, but I have not yet verified this.
projects / thirdparty / man-pages.git / log
