Posix shared memory problem

[Dag-Erling Smørgrav]

Lothar Scholz <scholz at scriptolutions.com> writes:
> Sujit K M <kmsujit at gmail.com> writes:
> > What needs to be fixed? Could you be more specific?
> That the name argument is just that "a name" (in its own name space)
> not a path.

Allow me to quote from the SUSv3 again:

DESCRIPTION

  The shm_open() function shall establish a connection between a shared
  memory object and a file descriptor.  [...]  The name argument points
  to a string naming a shared memory object.  It is unspecified whether
  the name appears in the file system and is visible to other functions
  that take pathnames as arguments.  The name argument conforms to the
  construction rules for a pathname.  [...]

RATIONALE

  [...]

  Note that such shared memory objects can actually be implemented as
  mapped files.  In both cases, the size can be set after the open using
  ftruncate().  The shm_open() function itself does not create a shared
  object of a specified size because this would duplicate an extant
  function that set the size of an object referenced by a file
  descriptor.

  On implementations where memory objects are implemented using the
  existing file system, the shm_open() function may be implemented using
  a macro that invokes open(), and the shm_unlink() function may be
  implemented using a macro that invokes unlink().

  [...]

DES
-- 
Dag-Erling Smørgrav - des at des.no