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.

-----------------------------------------------
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