How do I correctly determine NAME_MAX for shm_open?

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.

1. https://github.com/lattera/glibc/blob/master/sysdeps/posix/shm_open.c
2. https://github.com/lattera/glibc/blob/master/sysdeps/posix/shm-directory.h
3. 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