* _ISOCxx_SOURCE
From: Alejandro Colomar @ 2026-06-13 12:02 UTC (permalink / raw)
To: libc-alpha; +Cc: gcc, linux-man
[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]
Hi!
I was reviewing the feature_test_macros(7) page, and found the
documentation of the _ISOC{99,11,23,...}_SOURCE macros to be incorrect.
And thinking about fixing that led me to think that the design of those
macros is less than ideal.
Here's for example some of the problematic text:
Defining _ISOC23_SOURCE also enables C11, C99, and C95 features.
The above is not true. See for example some contradicting (and also
incorrect/incomplete) text in the HISTORY section of gets(3):
glibc header files don’t expose the function declaration if the
_ISOC11_SOURCE feature test macro is defined.
gets(3) is a C89 and C99 feature, which is disabled with C11 and later
standard versions. The text saying that _ISOC23_SOURCE enables older
features is only true as much as those features remain in the C23
standard. And in gets(3), we should say that the function is not
exposed on C11 or later (not just C11).
A better design of this macro would be to have a single identifier, and
use a value to specify the version. This is how POSIX does it. We
could call it _ISO_C_SOURCE, and have a value such as 202311L for
requesting C23. That would make it easier to describe: features are
available within a range of versions; often a half-bounded interval,
starting at a version, and not ending; but other times a bounded
interval, starting at a version, and ending at another version.
What do you think?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/6] ioctl_userfaultfd.2: Reference UFFDIO_RWPROTECT and UFFDIO_SET_MODE
From: Alejandro Colomar @ 2026-06-04 12:14 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-man, linux-mm, akpm, rppt, peterx, david, kernel-team
In-Reply-To: <aiFplwrPTalpnQqn@thinkstation>
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
Hi Kiryl,
On 2026-06-04T13:08:49+0100, Kiryl Shutsemau wrote:
> On Thu, Jun 04, 2026 at 01:47:42AM +0200, Alejandro Colomar wrote:
> > Hi Kiryl,
> >
> > On 2026-05-26T14:41:49+0100, Kiryl Shutsemau wrote:
> > > Add the two new ioctls introduced in Linux 7.2 to the list of
> > > operations supported on a userfaultfd file descriptor.
> > >
> > > Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> > > Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> >
> > Patch applied; thanks! With this one, the full set is applied.
>
> Thank you!
>
> But it looks like I was too optimistic about Linux 7.2. Looks like it
> slips to 7.3.
No problem.
> I don't expect any API changes in between.
Ok.
> How do you want to approach it? Do you want me to resend it with
> s/7\.2/7.3/g once it actually hits upstream?
>
I've already pushed the patches. You could send patches changing the
version numbers, once it actually hits upstream.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/6] ioctl_userfaultfd.2: Reference UFFDIO_RWPROTECT and UFFDIO_SET_MODE
From: Kiryl Shutsemau @ 2026-06-04 12:08 UTC (permalink / raw)
To: Alejandro Colomar
Cc: linux-man, linux-mm, akpm, rppt, peterx, david, kernel-team
In-Reply-To: <aiC9Be5oxT8u1Z6E@devuan>
On Thu, Jun 04, 2026 at 01:47:42AM +0200, Alejandro Colomar wrote:
> Hi Kiryl,
>
> On 2026-05-26T14:41:49+0100, Kiryl Shutsemau wrote:
> > Add the two new ioctls introduced in Linux 7.2 to the list of
> > operations supported on a userfaultfd file descriptor.
> >
> > Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> > Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>
> Patch applied; thanks! With this one, the full set is applied.
Thank you!
But it looks like I was too optimistic about Linux 7.2. Looks like it
slips to 7.3.
I don't expect any API changes in between.
How do you want to approach it? Do you want me to resend it with
s/7\.2/7.3/g once it actually hits upstream?
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: Error in manual page memcpy(3)
From: Alejandro Colomar @ 2026-06-04 11:03 UTC (permalink / raw)
To: Siegfried Ehlert; +Cc: linux-man
In-Reply-To: <e53068f4-2541-4220-8571-47e3283bb01f@netscape.net>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
Hi Siegfried,
On 2026-06-04T12:14:08+0200, Siegfried Ehlert wrote:
> An error has crept into the synopsis of the *memcpy(3)* manual page.
> Immediately after the opening bracket of the function name, the third
> argument is listed as "size_t n;". The same applies to the strncpy(3) and
> stpncpy(3) manual pages; there, too, the third argument appears immediately
> after the opening bracket.
>
> *Example:
> *
>
>
> SYNOPSIS
>
> *#include <string.h>* *void *memcpy(*size_t n; *void */dest/*[restrict
> */n/*], const void */src/*[restrict */n/*],* *size_t */n/*);*
That's correct.
void *memcpy(size_t n;
void dest[restrict n], const void src[restrict n], size_t n);
What you're seeing is a forward declaration of the third parameter.
This is necessary so that it can be used in the array length expressions
in the declarators of the first and second parameters, since the third
parameter hasn't been declared yet. This is an old GNU extension, and
is documented at the bottom of this page of the GCC manual:
<https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html>
Have a lovely day!
Alex
>
> Kind regards
> Siegfried
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 6/6] ioctl_userfaultfd.2: Reference UFFDIO_RWPROTECT and UFFDIO_SET_MODE
From: Alejandro Colomar @ 2026-06-03 23:47 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-man, linux-mm, akpm, rppt, peterx, david, kernel-team,
Kiryl Shutsemau
In-Reply-To: <20260526134149.2831720-7-kirill@shutemov.name>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
Hi Kiryl,
On 2026-05-26T14:41:49+0100, Kiryl Shutsemau wrote:
> Add the two new ioctls introduced in Linux 7.2 to the list of
> operations supported on a userfaultfd file descriptor.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Patch applied; thanks! With this one, the full set is applied.
Cheers,
Alex
> ---
> man/man2/ioctl_userfaultfd.2 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/man/man2/ioctl_userfaultfd.2 b/man/man2/ioctl_userfaultfd.2
> index 37553cd7a88f..fb57fe222979 100644
> --- a/man/man2/ioctl_userfaultfd.2
> +++ b/man/man2/ioctl_userfaultfd.2
> @@ -76,9 +76,13 @@ .SH DESCRIPTION
> .TQ
> .BR UFFDIO_WRITEPROTECT (2const)
> .TQ
> +.BR UFFDIO_RWPROTECT (2const)
> +.TQ
> .BR UFFDIO_CONTINUE (2const)
> .TQ
> .BR UFFDIO_POISON (2const)
> +.TQ
> +.BR UFFDIO_SET_MODE (2const)
> .SH RETURN VALUE
> On success,
> 0 is returned.
> --
> 2.54.0
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/6] UFFDIO_REGISTER.2const: Document UFFDIO_REGISTER_MODE_RWP and 1 << _UFFDIO_RWPROTECT
From: Alejandro Colomar @ 2026-06-03 23:46 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-man, linux-mm, akpm, rppt, peterx, david, kernel-team,
Kiryl Shutsemau
In-Reply-To: <20260526134149.2831720-6-kirill@shutemov.name>
[-- Attachment #1: Type: text/plain, Size: 2566 bytes --]
On 2026-05-26T14:41:48+0100, Kiryl Shutsemau wrote:
> Add the new registration mode bit introduced in Linux 7.2:
>
> UFFDIO_REGISTER_MODE_RWP Track every access (read or write) to a
> present page in the registered range.
> Cannot be combined with
> UFFDIO_REGISTER_MODE_WP; both modes share
> the same per-PTE marker bit. Anonymous,
> shmem, and hugetlbfs ranges are
> compatible.
>
> Also document the matching argp->ioctls bit, 1 << _UFFDIO_RWPROTECT,
> which the kernel reports only when the range was registered with
> UFFDIO_REGISTER_MODE_RWP (which itself requires UFFD_FEATURE_RWP to
> have been negotiated).
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Patch applied; thanks!
Cheers,
Alex
> ---
> man/man2const/UFFDIO_REGISTER.2const | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/man/man2const/UFFDIO_REGISTER.2const b/man/man2const/UFFDIO_REGISTER.2const
> index 50064c954b81..ded57cf301ad 100644
> --- a/man/man2const/UFFDIO_REGISTER.2const
> +++ b/man/man2const/UFFDIO_REGISTER.2const
> @@ -72,6 +72,20 @@ .SH DESCRIPTION
> only hugetlbfs ranges are compatible.
> Since Linux 5.14,
> compatibility with shmem ranges was added.
> +.TP
> +.BR UFFDIO_REGISTER_MODE_RWP " (since Linux 7.2)"
> +Track page faults on read-write-protected pages.
> +Every access
> +(read or write)
> +to a page present within the registered range
> +generates a notification
> +once the range has been protected with
> +.BR UFFDIO_RWPROTECT (2const).
> +This mode cannot be combined with
> +.BR UFFDIO_REGISTER_MODE_WP ;
> +attempting to do so fails with
> +.BR EINVAL .
> +Anonymous, shmem, and hugetlbfs ranges are compatible.
> .P
> If the operation is successful, the kernel modifies the
> .I argp->ioctls
> @@ -109,6 +123,16 @@ .SH DESCRIPTION
> The
> .B UFFDIO_POISON
> operation is supported.
> +.TP
> +.BR "1 << _UFFDIO_RWPROTECT" " (since Linux 7.2)"
> +The
> +.B UFFDIO_RWPROTECT
> +operation is supported.
> +This bit is reported only when the range was registered with
> +.B UFFDIO_REGISTER_MODE_RWP
> +(which itself requires
> +.B UFFD_FEATURE_RWP
> +to have been negotiated).
> .SH RETURN VALUE
> On success,
> 0 is returned.
> --
> 2.54.0
>
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/6] UFFDIO_API.2const: Document UFFD_FEATURE_RWP{,_ASYNC} and 1 << _UFFDIO_SET_MODE
From: Alejandro Colomar @ 2026-06-03 23:43 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-man, linux-mm, akpm, rppt, peterx, david, kernel-team,
Kiryl Shutsemau
In-Reply-To: <20260526134149.2831720-5-kirill@shutemov.name>
[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]
Hi Kiryl,
On 2026-05-26T14:41:47+0100, Kiryl Shutsemau wrote:
> Add the two RWP feature bits introduced in Linux 7.2:
>
> UFFD_FEATURE_RWP gates UFFDIO_REGISTER_MODE_RWP and the
> UFFDIO_RWPROTECT(2const) ioctl.
> UFFD_FEATURE_RWP_ASYNC in-kernel resolution of RWP faults without
> delivering a notification; requires
> UFFD_FEATURE_RWP to be set in the same
> UFFDIO_API call.
>
> Also document 1 << _UFFDIO_SET_MODE in argp->ioctls, the
> file-descriptor-level bit that advertises UFFDIO_SET_MODE(2const) for
> toggling UFFD_FEATURE_RWP_ASYNC at runtime; it is independent of any
> registered range.
>
> The existing page intro already describes UFFDIO_API returning EINVAL
> on unsupported feature bits and the temporary-uffd probe pattern, so
> the new TP entries do not re-state that.
>
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Thanks! I've applied the patch.
Have a lovely night!
Alex
> ---
> man/man2const/UFFDIO_API.2const | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/man/man2const/UFFDIO_API.2const b/man/man2const/UFFDIO_API.2const
> index e894114bb8e2..46ee7e31fed9 100644
> --- a/man/man2const/UFFDIO_API.2const
> +++ b/man/man2const/UFFDIO_API.2const
> @@ -213,6 +213,30 @@ .SH DESCRIPTION
> the kernel supports resolving faults with the
> .B UFFDIO_MOVE
> ioctl.
> +.TP
> +.BR UFFD_FEATURE_RWP " (since Linux 7.2)"
> +If this feature bit is set,
> +the kernel supports read-write-protection tracking,
> +and the
> +.B UFFDIO_REGISTER_MODE_RWP
> +registration mode and the
> +.B UFFDIO_RWPROTECT
> +ioctl become available.
> +.TP
> +.BR UFFD_FEATURE_RWP_ASYNC " (since Linux 7.2)"
> +If this feature bit is set,
> +the kernel will resolve read-write-protect faults in place
> +without delivering a notification,
> +automatically restoring page permissions
> +and letting the faulted thread continue.
> +This bit requires
> +.B UFFD_FEATURE_RWP
> +to be set in the same
> +.B UFFDIO_API
> +call.
> +The async mode can also be toggled at runtime using the
> +.BR UFFDIO_SET_MODE (2const)
> +ioctl.
> .P
> The returned
> .I argp->ioctls
> @@ -234,6 +258,13 @@ .SH DESCRIPTION
> The
> .B UFFDIO_UNREGISTER
> operation is supported.
> +.TP
> +.BR "1 << _UFFDIO_SET_MODE" " (since Linux 7.2)"
> +The
> +.B UFFDIO_SET_MODE
> +operation is supported.
> +This is a file-descriptor-level ioctl and is reported once per
> +userfaultfd, independent of any registered range.
> .SH RETURN VALUE
> On success,
> 0 is returned.
> --
> 2.54.0
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: man-pages-posix: possibly a typo in sendmsg(3p)
From: Alejandro Colomar @ 2026-06-02 11:40 UTC (permalink / raw)
To: Zhai Can; +Cc: linux-man
In-Reply-To: <0119ef36-2034-4c78-a0a5-86537f31468b@126.com>
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]
Hi Zhai,
On 2026-06-02T15:02:40+0800, Zhai Can wrote:
> Hi,
>
> https://man7.org/linux/man-pages/man3/sendmsg.3p.html
>
> In the EXAMPLES section it states a "Done." which is weird here. I suppose it
> should be a "None."? A quick grep shows the whole 3p manuals (2017) only have
> the one occurrence.
>
> ~/man-pages-posix-2017/man3p ❯ rg Done.
> sendmsg.3p
> 281:Done.
>
> It's an upstream issue. Also in:
>
> https://pubs.opengroup.org/onlinepubs/9799919799/
>
> I don't have an Austin group account unfortunately so could someone give a
> help and file this?
Done: <https://www.austingroupbugs.net/view.php?id=1983>. Thanks!
Have a lovely day!
Alex
>
> Thanks!
>
> --
> zc
>
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* man-pages-posix: possibly a typo in sendmsg(3p)
From: Zhai Can @ 2026-06-02 7:02 UTC (permalink / raw)
To: linux-man
Hi,
https://man7.org/linux/man-pages/man3/sendmsg.3p.html
In the EXAMPLES section it states a "Done." which is weird here. I suppose it
should be a "None."? A quick grep shows the whole 3p manuals (2017) only have
the one occurrence.
~/man-pages-posix-2017/man3p ❯ rg Done.
sendmsg.3p
281:Done.
It's an upstream issue. Also in:
https://pubs.opengroup.org/onlinepubs/9799919799/
I don't have an Austin group account unfortunately so could someone give a
help and file this?
Thanks!
--
zc
^ permalink raw reply
* Re: [PATCH v2] man/man2const/F_{ADD,GET}_SEALS.2const: document F_SEAL_EXEC
From: Alejandro Colomar @ 2026-06-01 23:41 UTC (permalink / raw)
To: Pratyush Yadav
Cc: David Hildenbrand, Daniel Verkamp, Jeff Xu, Pasha Tatashin,
Baolin Wang, Hugh Dickins, linux-man, linux-mm
In-Reply-To: <20260529140557.1624507-1-pratyush@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3362 bytes --]
Hi Pratyush,
On 2026-05-29T16:05:55+0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> F_SEAL_EXEC was added in Linux v6.3. It blocks changing of the exec bits
> once added. Document it.
>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>
> Notes:
> I discovered this was missing when working on [0]. I had to look at the
> code to figure out how it was supposed to behave.
>
> Changes in v2:
> - Re-write the documentation by hand.
>
> [0] https://lore.kernel.org/linux-mm/20260505133922.797635-1-pratyush@kernel.org/
Thanks! I've applied the patch, with a few minor tweaks:
diff --git i/man/man2const/F_GET_SEALS.2const w/man/man2const/F_GET_SEALS.2const
index f41e1748acd0..686a92fddefe 100644
--- i/man/man2const/F_GET_SEALS.2const
+++ w/man/man2const/F_GET_SEALS.2const
@@ -178,13 +178,15 @@ .SH DESCRIPTION
while sharing that buffer on a "read-only" basis with other processes.
.TP
.BR F_SEAL_EXEC " (since Linux 6.3)"
-If this seal is set, the execute mode bits of the file cannot be modified.
+If this seal is set,
+the execute mode bits of the file cannot be modified.
Attempting to change the execute mode bits via
.BR fchmod (2)
or similar will fail with
.BR EPERM .
-This results in a memfd that is either permanently executable or
-permanently un-executable.
+This results in a memfd that is
+either permanently executable
+or permanently not executable.
.IP
Adding this seal implicitly adds
.BR F_SEAL_GROW ,
@@ -193,7 +195,8 @@ .SH DESCRIPTION
and
.BR F_SEAL_FUTURE_WRITE .
This ensures that the executable code is not writeable.
-All the pre-requisites to add the implied seals must be met to successfully add
+All the pre-requisites to add the implied seals must be met
+to successfully add
.BR F_SEAL_EXEC .
.SH RETURN VALUE
.TP
Have a lovely night!
Alex
>
> man/man2const/F_GET_SEALS.2const | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/man/man2const/F_GET_SEALS.2const b/man/man2const/F_GET_SEALS.2const
> index 175025c10..f41e1748a 100644
> --- a/man/man2const/F_GET_SEALS.2const
> +++ b/man/man2const/F_GET_SEALS.2const
> @@ -176,6 +176,25 @@ will fail with
> Using this seal,
> one process can create a memory buffer that it can continue to modify
> while sharing that buffer on a "read-only" basis with other processes.
> +.TP
> +.BR F_SEAL_EXEC " (since Linux 6.3)"
> +If this seal is set, the execute mode bits of the file cannot be modified.
> +Attempting to change the execute mode bits via
> +.BR fchmod (2)
> +or similar will fail with
> +.BR EPERM .
> +This results in a memfd that is either permanently executable or
> +permanently un-executable.
> +.IP
> +Adding this seal implicitly adds
> +.BR F_SEAL_GROW ,
> +.BR F_SEAL_SHRINK ,
> +.BR F_SEAL_WRITE ,
> +and
> +.BR F_SEAL_FUTURE_WRITE .
> +This ensures that the executable code is not writeable.
> +All the pre-requisites to add the implied seals must be met to successfully add
> +.BR F_SEAL_EXEC .
> .SH RETURN VALUE
> .TP
> .B F_GET_SEALS
>
> base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
> --
> 2.54.0.1013.g208068f2d8-goog
>
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] man/man2/fanotify_mark.2: AT_FDCWD plus NULL path doesn't work
From: Alejandro Colomar @ 2026-06-01 22:19 UTC (permalink / raw)
To: Amir Goldstein, Heinrich Schuchardt
Cc: Jann Horn, Jan Kara, Matthew Bobrowski, linux-man, linux-fsdevel,
linux-kernel
In-Reply-To: <ahoIuOuC7q5M24dV@devuan>
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]
Hi,
On 2026-05-29T23:45:55+0200, Alejandro Colomar wrote:
> Hi Jann, Amir,
>
> On 2026-05-29T23:38:11+0200, Amir Goldstein wrote:
> > On Fri, May 29, 2026 at 7:27 PM Jann Horn <jannh@google.com> wrote:
> > >
> > > The fanotify_mark.2 manpage claims that AT_FDCWD works with a NULL path,
> > > but there is no kernel code for that - in fanotify_find_path(), in the
> > > `if (filename == NULL)` block, the fd is only used for a normal FD
> > > lookup.
> > >
> > > This was also already the case when this manpage was written back in
> > > 2014, so remove the bogus documentation.
> > >
> > > Fixes: c200b422d ("fanotify_mark.2: New page documenting fanotify_mark(2)")
> > > Signed-off-by: Jann Horn <jannh@google.com>
> >
> > Hah, never noticed this.
> > Apparently, hallucinations already existed in 2014 :D
> >
> > Acked-by: Amir Goldstein <amir73il@gmail.com>
>
> Thanks! I've added the author of the fixed commit in the recipients.
> I'll apply on Monday or so.
I've applied the patch and tag now. Thanks!
Have a lovely night!
Alex
>
>
> Have a lovely night!
> Alex
>
> >
> > > ---
> > > man/man2/fanotify_mark.2 | 8 --------
> > > 1 file changed, 8 deletions(-)
> > >
> > > diff --git a/man/man2/fanotify_mark.2 b/man/man2/fanotify_mark.2
> > > index e561ffd21..a3b77537c 100644
> > > --- a/man/man2/fanotify_mark.2
> > > +++ b/man/man2/fanotify_mark.2
> > > @@ -560,14 +560,6 @@ defines the filesystem object to be marked.
> > > .IP \[bu]
> > > If
> > > .I path
> > > -is NULL, and
> > > -.I dirfd
> > > -takes the special value
> > > -.BR AT_FDCWD ,
> > > -the current working directory is to be marked.
> > > -.IP \[bu]
> > > -If
> > > -.I path
> > > is absolute, it defines the filesystem object to be marked, and
> > > .I dirfd
> > > is ignored.
> > >
> > > ---
> > > base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
> > > change-id: 20260529-fan-mark-cwd-1c760106eff9
> > >
> > > Best regards,
> > > --
> > > Jann Horn <jannh@google.com>
> > >
> >
>
> --
> <https://www.alejandro-colomar.es>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: non-standard const-preserving string APIs
From: Alejandro Colomar @ 2026-06-01 22:10 UTC (permalink / raw)
To: Florian Weimer; +Cc: Adhemerval Zanella Netto, libc-alpha, linux-man
In-Reply-To: <87h5nmo5cz.fsf@oldenburg.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
Hi Florian,
On 2026-06-01T13:41:16+0200, Florian Weimer wrote:
> > I will try to take a look, but I recall from previous weekly calls
> > that Florian has raised objection that this does not solve the
> > overflow issue (not without further extra changes).
>
> <https://inbox.sourceware.org/libc-alpha/lhums05zjuh.fsf@oldenburg.str.redhat.com/>
>
> > I am not sure if he still keep his objection, nor if it is would a
> > blocker for this new api.
>
> I still think we should fix it. Maybe rename the “done” variable in the
> vfprintf internals to “ssize_t”, and then gradually fix the compilation
> failures, investigating whether the change is correct in context. We
> need to add some early bailout in case INT_MAX is crossed for the
> non-aprintf case.
Would you mind at least confirming whether the current patches are OK
modulo the EOVERFLOW issue? It's the first time I touch many of these
files (e.g., abilist files), and I'd appreciate if you reviewed it so
that I can forget about that part.
Have a lovely night!
Alex
>
> Thanks,
> Florian
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: non-standard const-preserving string APIs
From: Florian Weimer @ 2026-06-01 11:41 UTC (permalink / raw)
To: Adhemerval Zanella Netto; +Cc: Alejandro Colomar, libc-alpha, linux-man
In-Reply-To: <0c1e8b52-68d3-4be4-84aa-8ab5bdfee29a@linaro.org>
* Adhemerval Zanella Netto:
> On 17/05/26 10:59, Alejandro Colomar wrote:
>> Hi Adhemerval,
>>
>> On 2026-05-17T09:22:41-0300, Adhemerval Zanella Netto wrote:
>>>
>>>
>>> On 16/05/26 15:15, Alejandro Colomar wrote:
>>>> Hi!
>>>>
>>>> I'm working on documenting the recent API change of strchr(3) et al.
>>>> to adapt to C23. While doing that, I've realized that the related APIs
>>>> that are not standardized by ISO C, such as memrchr(3), have not been
>>>> changed consistently with their relatives. Has this been discussed?
>>>>
>>>> I think the inconsistency might be dangerous. Should we change the
>>>> other string functions accordingly?
>>> I think it is reasonable to support const-preserving to the GNU interfaces as
>>> well. Are you preparing a patch?
>>
>> Yup, I will. Thanks!
> I will try to take a look, but I recall from previous weekly calls
> that Florian has raised objection that this does not solve the
> overflow issue (not without further extra changes).
<https://inbox.sourceware.org/libc-alpha/lhums05zjuh.fsf@oldenburg.str.redhat.com/>
> I am not sure if he still keep his objection, nor if it is would a
> blocker for this new api.
I still think we should fix it. Maybe rename the “done” variable in the
vfprintf internals to “ssize_t”, and then gradually fix the compilation
failures, investigating whether the change is correct in context. We
need to add some early bailout in case INT_MAX is crossed for the
non-aprintf case.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH] man/man2/fanotify_mark.2: AT_FDCWD plus NULL path doesn't work
From: Alejandro Colomar @ 2026-05-29 21:45 UTC (permalink / raw)
To: Amir Goldstein, Heinrich Schuchardt
Cc: Jann Horn, Jan Kara, Matthew Bobrowski, linux-man, linux-fsdevel,
linux-kernel
In-Reply-To: <CAOQ4uxiHU5xK=_FsOBkkB0go9ACBb2fYcdVE6T2o=MYDcxaiaQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
Hi Jann, Amir,
On 2026-05-29T23:38:11+0200, Amir Goldstein wrote:
> On Fri, May 29, 2026 at 7:27 PM Jann Horn <jannh@google.com> wrote:
> >
> > The fanotify_mark.2 manpage claims that AT_FDCWD works with a NULL path,
> > but there is no kernel code for that - in fanotify_find_path(), in the
> > `if (filename == NULL)` block, the fd is only used for a normal FD
> > lookup.
> >
> > This was also already the case when this manpage was written back in
> > 2014, so remove the bogus documentation.
> >
> > Fixes: c200b422d ("fanotify_mark.2: New page documenting fanotify_mark(2)")
> > Signed-off-by: Jann Horn <jannh@google.com>
>
> Hah, never noticed this.
> Apparently, hallucinations already existed in 2014 :D
>
> Acked-by: Amir Goldstein <amir73il@gmail.com>
Thanks! I've added the author of the fixed commit in the recipients.
I'll apply on Monday or so.
Have a lovely night!
Alex
>
> > ---
> > man/man2/fanotify_mark.2 | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/man/man2/fanotify_mark.2 b/man/man2/fanotify_mark.2
> > index e561ffd21..a3b77537c 100644
> > --- a/man/man2/fanotify_mark.2
> > +++ b/man/man2/fanotify_mark.2
> > @@ -560,14 +560,6 @@ defines the filesystem object to be marked.
> > .IP \[bu]
> > If
> > .I path
> > -is NULL, and
> > -.I dirfd
> > -takes the special value
> > -.BR AT_FDCWD ,
> > -the current working directory is to be marked.
> > -.IP \[bu]
> > -If
> > -.I path
> > is absolute, it defines the filesystem object to be marked, and
> > .I dirfd
> > is ignored.
> >
> > ---
> > base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
> > change-id: 20260529-fan-mark-cwd-1c760106eff9
> >
> > Best regards,
> > --
> > Jann Horn <jannh@google.com>
> >
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] man/man2/fanotify_mark.2: AT_FDCWD plus NULL path doesn't work
From: Amir Goldstein @ 2026-05-29 21:38 UTC (permalink / raw)
To: Jann Horn
Cc: Alejandro Colomar, Jan Kara, Matthew Bobrowski, linux-man,
linux-fsdevel, linux-kernel
In-Reply-To: <20260529-fan-mark-cwd-v1-1-cdfb3b5b6d7c@google.com>
On Fri, May 29, 2026 at 7:27 PM Jann Horn <jannh@google.com> wrote:
>
> The fanotify_mark.2 manpage claims that AT_FDCWD works with a NULL path,
> but there is no kernel code for that - in fanotify_find_path(), in the
> `if (filename == NULL)` block, the fd is only used for a normal FD
> lookup.
>
> This was also already the case when this manpage was written back in
> 2014, so remove the bogus documentation.
>
> Fixes: c200b422d ("fanotify_mark.2: New page documenting fanotify_mark(2)")
> Signed-off-by: Jann Horn <jannh@google.com>
Hah, never noticed this.
Apparently, hallucinations already existed in 2014 :D
Acked-by: Amir Goldstein <amir73il@gmail.com>
> ---
> man/man2/fanotify_mark.2 | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/man/man2/fanotify_mark.2 b/man/man2/fanotify_mark.2
> index e561ffd21..a3b77537c 100644
> --- a/man/man2/fanotify_mark.2
> +++ b/man/man2/fanotify_mark.2
> @@ -560,14 +560,6 @@ defines the filesystem object to be marked.
> .IP \[bu]
> If
> .I path
> -is NULL, and
> -.I dirfd
> -takes the special value
> -.BR AT_FDCWD ,
> -the current working directory is to be marked.
> -.IP \[bu]
> -If
> -.I path
> is absolute, it defines the filesystem object to be marked, and
> .I dirfd
> is ignored.
>
> ---
> base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
> change-id: 20260529-fan-mark-cwd-1c760106eff9
>
> Best regards,
> --
> Jann Horn <jannh@google.com>
>
^ permalink raw reply
* [PATCH] man/man2/fanotify_mark.2: AT_FDCWD plus NULL path doesn't work
From: Jann Horn @ 2026-05-29 17:27 UTC (permalink / raw)
To: Alejandro Colomar, Jan Kara, Amir Goldstein, Matthew Bobrowski
Cc: linux-man, linux-fsdevel, linux-kernel, Jann Horn
The fanotify_mark.2 manpage claims that AT_FDCWD works with a NULL path,
but there is no kernel code for that - in fanotify_find_path(), in the
`if (filename == NULL)` block, the fd is only used for a normal FD
lookup.
This was also already the case when this manpage was written back in
2014, so remove the bogus documentation.
Fixes: c200b422d ("fanotify_mark.2: New page documenting fanotify_mark(2)")
Signed-off-by: Jann Horn <jannh@google.com>
---
man/man2/fanotify_mark.2 | 8 --------
1 file changed, 8 deletions(-)
diff --git a/man/man2/fanotify_mark.2 b/man/man2/fanotify_mark.2
index e561ffd21..a3b77537c 100644
--- a/man/man2/fanotify_mark.2
+++ b/man/man2/fanotify_mark.2
@@ -560,14 +560,6 @@ defines the filesystem object to be marked.
.IP \[bu]
If
.I path
-is NULL, and
-.I dirfd
-takes the special value
-.BR AT_FDCWD ,
-the current working directory is to be marked.
-.IP \[bu]
-If
-.I path
is absolute, it defines the filesystem object to be marked, and
.I dirfd
is ignored.
---
base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
change-id: 20260529-fan-mark-cwd-1c760106eff9
Best regards,
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* Re: Linux Man Rendering Issue - Resend
From: Alejandro Colomar @ 2026-05-29 14:26 UTC (permalink / raw)
To: Chris Adams; +Cc: linux-man
In-Reply-To: <CAJ8owHS3QMOykxJTveCSB5iSiSUVKtswVjDaBJ6cos06whB3AA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
Hi Chris,
On 2026-05-29T10:16:40-0400, Chris Adams wrote:
> Hello,
>
> I’m writing to let you know that the rendering of links within the
> description sections of Linux manual pages is currently borked. I
> apologize if this is a known issue. Behavior persists across standard
> browsers and devices. Thank you for your work on this project!
Thanks! This was reported earlier today:
<https://lore.kernel.org/linux-man/20260529111929.7vvqnyie3ankf4ec@illithid/T/>
man7.org is Michael Kerrisks's page, and is not officially part of this
project. However, I do have contact with Michael, and he has received
the report (I don't know if he's read it yet, though).
Have a lovely day!
Alex
> Best,
>
> Chris Adams
>
> *Message resent due to linux-man spam filter.
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Linux Man Rendering Issue - Resend
From: Chris Adams @ 2026-05-29 14:16 UTC (permalink / raw)
To: alx; +Cc: linux-man
Hello,
I’m writing to let you know that the rendering of links within the
description sections of Linux manual pages is currently borked. I
apologize if this is a known issue. Behavior persists across standard
browsers and devices. Thank you for your work on this project!
Best,
Chris Adams
*Message resent due to linux-man spam filter.
^ permalink raw reply
* [PATCH v2] man/man2const/F_{ADD,GET}_SEALS.2const: document F_SEAL_EXEC
From: Pratyush Yadav @ 2026-05-29 14:05 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Pratyush Yadav (Google), David Hildenbrand, Daniel Verkamp,
Jeff Xu, Pasha Tatashin, Baolin Wang, Hugh Dickins, linux-man,
linux-mm
From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
F_SEAL_EXEC was added in Linux v6.3. It blocks changing of the exec bits
once added. Document it.
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
Notes:
I discovered this was missing when working on [0]. I had to look at the
code to figure out how it was supposed to behave.
Changes in v2:
- Re-write the documentation by hand.
[0] https://lore.kernel.org/linux-mm/20260505133922.797635-1-pratyush@kernel.org/
man/man2const/F_GET_SEALS.2const | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/man/man2const/F_GET_SEALS.2const b/man/man2const/F_GET_SEALS.2const
index 175025c10..f41e1748a 100644
--- a/man/man2const/F_GET_SEALS.2const
+++ b/man/man2const/F_GET_SEALS.2const
@@ -176,6 +176,25 @@ will fail with
Using this seal,
one process can create a memory buffer that it can continue to modify
while sharing that buffer on a "read-only" basis with other processes.
+.TP
+.BR F_SEAL_EXEC " (since Linux 6.3)"
+If this seal is set, the execute mode bits of the file cannot be modified.
+Attempting to change the execute mode bits via
+.BR fchmod (2)
+or similar will fail with
+.BR EPERM .
+This results in a memfd that is either permanently executable or
+permanently un-executable.
+.IP
+Adding this seal implicitly adds
+.BR F_SEAL_GROW ,
+.BR F_SEAL_SHRINK ,
+.BR F_SEAL_WRITE ,
+and
+.BR F_SEAL_FUTURE_WRITE .
+This ensures that the executable code is not writeable.
+All the pre-requisites to add the implied seals must be met to successfully add
+.BR F_SEAL_EXEC .
.SH RETURN VALUE
.TP
.B F_GET_SEALS
base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* Re: [PATCH] man/man2const/F_{ADD,GET}_SEALS.2const: document F_SEAL_EXEC
From: Pratyush Yadav @ 2026-05-29 13:28 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Pratyush Yadav, David Hildenbrand, Daniel Verkamp, Jeff Xu,
Pasha Tatashin, Baolin Wang, Hugh Dickins, linux-man, linux-mm
In-Reply-To: <ahmPrpekhMwD-8fD@devuan>
On Fri, May 29 2026, Alejandro Colomar wrote:
> Hi Pratyush,
>
> On 2026-05-29T14:40:44+0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>>
>> F_SEAL_EXEC was added in Linux v6.3. It seals the exec bits of the
>> memfd. Document it.
>>
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>
>> Notes:
>> I discovered this was missing when working on [0]. I had to look at the
>> code to figure out how it was supposed to behave.
>>
>> Disclaimer: I used help from Gemini to write this patch, mainly because
>> I don't know the man page syntax. If the man-pages project also uses the
>> AI-assisted tags as Linux, feel free to add:
>>
>> Assisted-by: Gemini:gemini-3.1-pro
>
> $ head -n13 CONTRIBUTING.d/ai
> Name
> AI - artificial intelligence policy
>
> Description
> It is expressly forbidden to contribute to this project any
> content that has been created or derived with the assistance of
> AI tools.
>
> This includes AI assistive tools used in the contributing
> process, even if such tools do not directly generate the
> contributed code but are used to derive the contribution. For
> example, AI linters, AI static analyzers, and AI tools that
> summarize input are forbidden.
Oh, well, that's a bummer :-(. I do understand the concerns, especially
the copyright one, but unfortunately I'm bummed about redoing an
otherwise perfectly good patch. These AI tools do make this sort of
stuff a tad bit easier.
Anyway, as you say, the amount of text is relatively small so I can redo
it by hand.
>
> If you only used it for formatting, and the text is entirely yours, I
> guess you'll be able to write it again from scratch easily (it's not
> a lot of text, anyway).
>
> To proceed clean, you should remove the patch entirely, and write it
> again from scratch, only looking at surrounding code and other pages,
> but not looking at the contaminated patch.
>
> If you have any doubts about the man(7) language, I can help, or even
> fix things for you (as long as it's reasonably easy to do so).
>
> Thanks!
>
>
> Have a lovely day!
> Alex
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH] man/man2const/F_{ADD,GET}_SEALS.2const: document F_SEAL_EXEC
From: Alejandro Colomar @ 2026-05-29 13:12 UTC (permalink / raw)
To: Pratyush Yadav
Cc: David Hildenbrand, Daniel Verkamp, Jeff Xu, Pasha Tatashin,
Baolin Wang, Hugh Dickins, linux-man, linux-mm
In-Reply-To: <20260529124047.1483026-1-pratyush@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
Hi Pratyush,
On 2026-05-29T14:40:44+0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> F_SEAL_EXEC was added in Linux v6.3. It seals the exec bits of the
> memfd. Document it.
>
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>
> Notes:
> I discovered this was missing when working on [0]. I had to look at the
> code to figure out how it was supposed to behave.
>
> Disclaimer: I used help from Gemini to write this patch, mainly because
> I don't know the man page syntax. If the man-pages project also uses the
> AI-assisted tags as Linux, feel free to add:
>
> Assisted-by: Gemini:gemini-3.1-pro
$ head -n13 CONTRIBUTING.d/ai
Name
AI - artificial intelligence policy
Description
It is expressly forbidden to contribute to this project any
content that has been created or derived with the assistance of
AI tools.
This includes AI assistive tools used in the contributing
process, even if such tools do not directly generate the
contributed code but are used to derive the contribution. For
example, AI linters, AI static analyzers, and AI tools that
summarize input are forbidden.
If you only used it for formatting, and the text is entirely yours, I
guess you'll be able to write it again from scratch easily (it's not
a lot of text, anyway).
To proceed clean, you should remove the patch entirely, and write it
again from scratch, only looking at surrounding code and other pages,
but not looking at the contaminated patch.
If you have any doubts about the man(7) language, I can help, or even
fix things for you (as long as it's reasonably easy to do so).
Thanks!
Have a lovely day!
Alex
>
> [0] https://lore.kernel.org/linux-mm/20260505133922.797635-1-pratyush@kernel.org/
>
> man/man2const/F_GET_SEALS.2const | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/man/man2const/F_GET_SEALS.2const b/man/man2const/F_GET_SEALS.2const
> index 175025c10..2de8009a8 100644
> --- a/man/man2const/F_GET_SEALS.2const
> +++ b/man/man2const/F_GET_SEALS.2const
> @@ -176,6 +176,25 @@ will fail with
> Using this seal,
> one process can create a memory buffer that it can continue to modify
> while sharing that buffer on a "read-only" basis with other processes.
> +.TP
> +.BR F_SEAL_EXEC " (since Linux 6.3)"
> +If this seal is set, the execute bits in the file mode cannot be modified.
> +Any attempt to modify these bits via
> +.BR chmod (2),
> +.BR fchmod (2),
> +or similar calls will fail with
> +.BR EPERM .
> +This preserves the execute bits as they were at the time of sealing,
> +making the file either permanently executable or permanently unexecutable.
> +.IP
> +If this seal is applied to a file that is already executable,
> +the kernel also implicitly applies
> +.BR F_SEAL_SHRINK ,
> +.BR F_SEAL_GROW ,
> +.BR F_SEAL_WRITE ,
> +and
> +.BR F_SEAL_FUTURE_WRITE ,
> +preventing any further modifications to the contents of the file.
> .SH RETURN VALUE
> .TP
> .B F_GET_SEALS
>
> base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
> --
> 2.54.0.1013.g208068f2d8-goog
>
>
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] man/man2const/F_{ADD,GET}_SEALS.2const: document F_SEAL_EXEC
From: Pratyush Yadav @ 2026-05-29 12:40 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Pratyush Yadav (Google), David Hildenbrand, Daniel Verkamp,
Jeff Xu, Pasha Tatashin, Baolin Wang, Hugh Dickins, linux-man,
linux-mm
From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
F_SEAL_EXEC was added in Linux v6.3. It seals the exec bits of the
memfd. Document it.
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
---
Notes:
I discovered this was missing when working on [0]. I had to look at the
code to figure out how it was supposed to behave.
Disclaimer: I used help from Gemini to write this patch, mainly because
I don't know the man page syntax. If the man-pages project also uses the
AI-assisted tags as Linux, feel free to add:
Assisted-by: Gemini:gemini-3.1-pro
[0] https://lore.kernel.org/linux-mm/20260505133922.797635-1-pratyush@kernel.org/
man/man2const/F_GET_SEALS.2const | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/man/man2const/F_GET_SEALS.2const b/man/man2const/F_GET_SEALS.2const
index 175025c10..2de8009a8 100644
--- a/man/man2const/F_GET_SEALS.2const
+++ b/man/man2const/F_GET_SEALS.2const
@@ -176,6 +176,25 @@ will fail with
Using this seal,
one process can create a memory buffer that it can continue to modify
while sharing that buffer on a "read-only" basis with other processes.
+.TP
+.BR F_SEAL_EXEC " (since Linux 6.3)"
+If this seal is set, the execute bits in the file mode cannot be modified.
+Any attempt to modify these bits via
+.BR chmod (2),
+.BR fchmod (2),
+or similar calls will fail with
+.BR EPERM .
+This preserves the execute bits as they were at the time of sealing,
+making the file either permanently executable or permanently unexecutable.
+.IP
+If this seal is applied to a file that is already executable,
+the kernel also implicitly applies
+.BR F_SEAL_SHRINK ,
+.BR F_SEAL_GROW ,
+.BR F_SEAL_WRITE ,
+and
+.BR F_SEAL_FUTURE_WRITE ,
+preventing any further modifications to the contents of the file.
.SH RETURN VALUE
.TP
.B F_GET_SEALS
base-commit: 9db8ca91f920b9aba40ed68de6b8da0ca9dbefaa
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* Re: Incorrect parsing of OSC 8 hyperlinks
From: G. Branden Robinson @ 2026-05-29 11:19 UTC (permalink / raw)
To: Pádraig Brady
Cc: Alejandro Colomar, Michael Kerrisk (man-pages),
linux-man@vger.kernel.org
In-Reply-To: <0f4714dc-fea7-4d8d-8942-85c4c592f7fc@draigBrady.com>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
At 2026-05-29T12:08:32+0100, Pádraig Brady wrote:
> I see all the coreutils man pages on man7.org are corrupted,
> due to the misparsing of OSC 8 hyper links output by --help.
I think a recent message of mine to the coreutils list:
https://lists.gnu.org/r/coreutils/2026-05/msg00080.html
...might have passed you in the night.
> As a quick fix you can set the TERM=dumb environment variable
> which will suppress these escapes.
On that note, I'd like to take this opportunity to solicit votes for a
change I've proposed for groff 1.25 (expected in July).
https://savannah.gnu.org/bugs/?67947
Is anyone reading interested in that?
Also, I think Michael might be interested in:
https://savannah.gnu.org/bugs/?66401
> Note the help2man that is shipped with coreutils (in man/help2man)
> is updated to support these escapes.
>
> The escaping should be quite easy to parse though,
> if you wanted to implement full support.
> For example the arch html generator supports this as can be seen at:
> https://man.archlinux.org/man/tee.1
I'd be surprised if device extension escape sequences (`\X'tty: link'`)
are easier to parse than `UR` and `MT` macro arguments.
But I could be wrong. I'm going by my nose on that question.
Regards,
Branden
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Incorrect parsing of OSC 8 hyperlinks
From: Pádraig Brady @ 2026-05-29 11:08 UTC (permalink / raw)
To: Alejandro Colomar, Michael Kerrisk (man-pages); +Cc: linux-man@vger.kernel.org
I see all the coreutils man pages on man7.org are corrupted,
due to the misparsing of OSC 8 hyper links output by --help.
As a quick fix you can set the TERM=dumb environment variable
which will suppress these escapes.
Note the help2man that is shipped with coreutils (in man/help2man)
is updated to support these escapes.
The escaping should be quite easy to parse though,
if you wanted to implement full support.
For example the arch html generator supports this as can be seen at:
https://man.archlinux.org/man/tee.1
thanks,
Padraig.
^ permalink raw reply
* Re: Mangled function prototypes (phantom arguments)
From: Mark Harris @ 2026-05-28 23:22 UTC (permalink / raw)
To: Alejandro Colomar
Cc: Carlos O'Donell, Michael Kerrisk (man7.org), linux-man
In-Reply-To: <ahjGLWkhne6VItJf@devuan>
Alejandro Colomar wrote:
>
> On 2026-05-28T23:24:06+0200, Alejandro Colomar wrote:
> > Hi Carlos,
> >
> > On 2026-05-28T14:39:15-0400, Carlos O'Donell wrote:
> > > On 5/28/26 9:06 AM, Michael Kerrisk (man7.org) wrote:
> > > > I don't think the Linux system call and C library manual pages are a
> > > > good place to promote this obscure GNU feature. It is confusing
> > > > people, including me. (I came to making this report because several
> > > > people have reported this "bug" on various pages rendered at
> > > > man7.org.)
> > > >
> > > > Please consider reverting these changes. These markings use
> > > > little-understood, nonportable syntax. The manual page synopses should
> > > > be in standard, portable C that is *easy* to understand.
> > >
> > > I agree with Michael.
> > >
> > > I think these changes should be reverted, but it's a question of
> > > goals and values for the project, and the purpose of the SYNOPSIS.
> > >
> > > My view was always that they were the simplest expression of the
> > > interface that the widest possible audience could understand, and
> > > that seems to align with Michael's view.
> >
> > That doesn't provide much value, IMHO. My opinion of the SYNOPSIS is
> > that it's a quick reminder of how a function should be used.
> >
> > Let's take a real example:
> >
> > long mbind(void *addr, unsigned long len, int mode,
> > const unsigned long *nodemask, unsigned long maxnode,
> > unsigned int flags);
> >
> > I honestly don't know anything from the prototype above. Apart from the
> > types, there's no useful information. There are the names which will
> > later be described in the description, but so far they're not useful.
> >
> > long mbind(unsigned long size, unsigned long maxnode;
> > void addr[size], unsigned long size, int mode,
> > const unsigned long nodemask[(maxnode + ULONG_WIDTH - 1)
> > / ULONG_WIDTH],
> > unsigned long maxnode, unsigned int flags);
> >
> > This already introduces me the function quite well. The description
> > will of course clarify details, but I can already see some things.
> >
> > > It certainly isn't for me as a C library author...
> >
> > The SYNOPSIS is for everyone. I read the synopses regularly while
> > programming. In fact, I read it quite more than the descriptions, which
> > I only read seldom, when interested in some rare details.
> >
> > > it's for
> > > someone just learning or refreshing knowledge, and what makes
> > > it easiest for a new person or someone less familiar to consume?
> >
> > Speaking of myself as a new programmer not so long ago, I would have
> > appreciated these synopses.
> >
> > > It seems like we've drifted toward describing the interface *and*
> > > the constraints in a compact form (like N3433). Is that in line
> > > with the goals of the project?
> >
> > I think it is. At least with how I see it.
> >
> > I also don't see much difference between the interface and its
> > constraints. They are deeply related (array parameters are part of the
> > type system, after all). If we wanted to know the names of the
> > arguments and their order, we could have something much simpler:
> >
> > mbind(addr, size, mode, nodemask, maxnode, flags);
>
> BTW, FWIW, this resembles quite a lot the documentation from the times
> of V7 Unix. Here's how functions were documented back then.
>
> SYNOPSIS
> char *ttyname(fildes)
>
> isatty(fildes)
>
> ttyslot()
>
> AFAICS, 4.4BSD is the first BSD that used function prototypes (both in
> the source code and documentation). You could similarly argue that that
> was unnecessarily confusing programmers back then (most programmers of
> the time might not be aware of the innovation of function prototypes,
> and why one would care about parameter types, especially when being
> introduced to a function). However, we'll probably agree that that was
> a good change. I would find a prototype without types to be quite
> uninformative.
The types are documented. Originally the types of arguments and the
return type of a function defaulted to int, so there is no need to
write the type in that case. Argument and return types that were not
int were shown in the man pages, using the syntax that was used at the
time (arguments declared with their type after the close parenthesis
before the open brace).
The issue is not the inclusion of additional information, the issue is
the use of obscure non-standard syntax that introduces confusion. The
man page above uses the normal C syntax that C programmers at the time
were very familiar with.
- Mark
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox