Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!seismo!cmcl2!rna!dan
From: dan@rna.UUCP (Dan Ts'o)
Newsgroups: net.unix-wizards
Subject: Re: System V shared memory and Ultrix ?
Message-ID: <550@rna.UUCP>
Date: Fri, 26-Sep-86 20:02:45 EDT
Article-I.D.: rna.550
Posted: Fri Sep 26 20:02:45 1986
Date-Received: Tue, 30-Sep-86 05:56:32 EDT
References: <547@rna.UUCP> <548@rna.UUCP> <168@rayssd.UUCP>
Reply-To: dan@rna.UUCP (Dan Ts'o)
Organization: Rockefeller Neurobiology
Lines: 20

In article <168@rayssd.UUCP> dpw@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.