System V shared memory and Ultrix ?

[Dan Ts'o]

In article <168 at rayssd.UUCP> dpw at rayssd.UUCP (Darryl P. Wagoner) writes:
>System V standard for IPC.  The only routine that is currently in the stdipc
>package is ftok, which when called and passed a file name and an "id", it 
>returns a unique key in key_t (long int) format.  The key is based on the 
>id (8 bits) minor device name (8 bits) and the inode number (16 bits).  By 
>different processes knowing what file name and "id" that was passed to ftok, 
>they can get the same key and therefore access the same shared memory.  The 
>trick is to insure that all IPC programs adhere to this standard.  
	Since ftok() doesn't make use of the major device number, I would think
that one could get screwed.
	Also it appears that ftok() returns -1 if it can't stat() the filename
which is reasonable except that the user program had better check for it before
blindly giving it to sh*() otherwise many segments will have -1 as the key.
ftok() should probably be smarted than this if it is truly going to be the
standard convention for creating key_t's.
	Thanks for all the sh*() hints. In particular, thanks for reminding
me about ftok(). The reason that I had "forgotten" about ftok() is that it
doesn't appears to be in the older System V manuals and Ultrix-32 has stuck
ftok(3C) in the C (compatibility) section of the manual without any cross-
reference.