On Mon, Apr 15, 2024 at 08:02:59PM +0200, Lorenz (xha) wrote:
> it doesn't make sense to me to document that you can set O_NOFOLLOW
> and O_CLOEXEC on the file descriptor even though they are always
> unconditionally set. also, imo O_NOFOLLOW should not be mentioned
> at all because that is just internal to the implementation.
> 

so kettenis@ has told me that he thinks the current wording is fine, so
as far as i'm concerned, i consider this case closed.

thanks for your submission though!
jmc

> -----------------------------------------------
> commit 70ba22c32324e30792d4fbd8d84c5b643d9ffa00 (master)
> from: Lorenz (xha) <me@xha.li>
> date: Mon Apr 15 17:57:27 2024 UTC
>  
>  don't mention O_NOFOLLOW and O_CLOEXEC in the shm_open(3) manual page
>  
>  and add that the close-on-exec flag is always set.
>  
> diff 32c7aa28d650443d91b49ffd9d0313439f3294ec 70ba22c32324e30792d4fbd8d84c5b643d9ffa00
> commit - 32c7aa28d650443d91b49ffd9d0313439f3294ec
> commit + 70ba22c32324e30792d4fbd8d84c5b643d9ffa00
> blob - 02e3c3aba65801519b3a5d0a2d6823611dd9b79c
> blob + 25ffc3b3b0b785527e6593a97c7b2cdaffffbdec
> --- lib/libc/gen/shm_open.3
> +++ lib/libc/gen/shm_open.3
> @@ -45,12 +45,13 @@ and must include at least
>  or
>  .Dv O_RDWR
>  and may also include a combination of
> -.Dv O_CREAT , O_EXCL , O_CLOEXEC , O_NOFOLLOW ,
> +.Dv O_CREAT , O_EXCL ,
>  or
>  .Dv O_TRUNC .
>  This implementation forces the
>  .Fa mode
>  to be 0600 or 0400, and prohibits sharing between different UIDs.
> +The close-on-exec flag is always set for the new file descriptor.
>  .Pp
>  .Fn shm_unlink
>  is used to remove a shared memory object.
> @@ -81,13 +82,6 @@ and
>  .Fn shm_unlink
>  appear in
>  .St -p1003.1-2001 .
> -Using
> -.Dv O_CLOEXEC
> -or
> -.Dv O_NOFOLLOW
> -with
> -.Fn shm_open
> -is an extension to that standard.
>  This implementation deviates from the standard by permitting less sharing.
>  .Pp
>  .Fn shm_mkstemp
>