In the manual page for shm_open
, we see that the argument for the name
parameter should be up to NAME_MAX
characters long for portable use.
However, in The GNU C Library Reference Manual’s section entitled "Limits on File System Capacity" we see that NAME_MAX
is not defined in "limits.h" on a system if it "allows different file systems or files to have different limits. We are told to use pathconf
instead.
However, pathconf
requires an actual path (or file descriptor) to use. What path should we use for shared memory objects as used by shm_open
. From what I understand, this is handled internally by glibc. On Linux, it is often, but not necessarily, "/dev/shm".
I would prefer not to use 255
directly as mentioned in the manual page for shm_open
. It doesn’t seem like a good idea to just use "/" since "/dev/shm" is often tmpfs, which differs from the root file system.
I tried grepping the header files and the output of getconf -a
and looking through other related manual pages, but I don’t see anything on how to do this.
I tracked down the code that opens a shared memory object in glibc but that was fairly unhelpful since it’s basically hard-coded.
- https://github.com/lattera/glibc/blob/master/sysdeps/posix/shm_open.c
- https://github.com/lattera/glibc/blob/master/sysdeps/posix/shm-directory.h
- https://github.com/lattera/glibc/blob/master/sysdeps/posix/shm-directory.c
Maybe that means I’m underestimating how portable "/dev/shm" is?
You need to sign in to view this answers
Leave feedback about this