Posix shared memory problem

Lothar Scholz scholz at scriptolutions.com
Mon May 11 09:29:54 UTC 2009

Hello Garrett,

Sunday, May 10, 2009, 5:54:31 PM, you wrote:

GW> <<On Sun, 10 May 2009 07:57:06 +0200, Lothar Scholz
GW> <scholz at scriptolutions.com> said:

>> First of all you can't use '/' if you want stay portable.

GW> The Standard says otherwise.

It's not a standard think. Read about the real world programming
hints. You see recommendations to only use a starting '/'

>> It is also just a maximum of 13 char long (says the FreeBSD 6.X man page)

GW> Not in the manual page I have, and the Standard says otherwise.

This time you are right. It was about named semaphores and there
the limit seems to be removed - it was ridiculous low anyway.

GW> Again, the Standard says otherwise (or rather, it says that this is an
GW> implementation option).  To quote the 2001 edition of the standard
GW> (XSH6 page 1313):

GW>         It is unspecified whether the name appears in the file system
GW>         and is visible to other functions that take pathnames as
GW>         arguments. The name argument conforms to the construction
GW>         rules for a pathname.

Thats why the man page calls this parameter 'name' and not 'path'.

Some idiots started to think about this as a file path. But it isn't
and it shouldn't. Thats what this spec is saying in the typical commitee
polite form when some members made a mistake but are to important to
be blamed in public.

So this needs to be fixed.

If i have to find a useable filefile location anyway the whole function does
not make any sense, then i can directly use mmap. The purpose is to
have a unique name (and in 2009 it is an URI not a file path). Thats
how serious non kiddy operating systems are doing like

And i guess also the accounting functions are wrong then. shm_open
does not open a file so the (internal used) file should not add to the
file space quota but to the memory allocation quota.

Best regards,
 Lothar Scholz                mailto:scholz at scriptolutions.com

More information about the freebsd-arch mailing list