This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
RE: MIT shared memory extension
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Robert Collins" <robert dot collins at itdomain dot com dot au>,"Cygwin-Xfree" <cygwin-xfree at sources dot redhat dot com>
- Date: Thu, 9 May 2002 21:35:39 +0200
- Subject: RE: MIT shared memory extension
Robert Collins wrote:
> In short, I don't like the idea of making key_t 32 bits.
>
I have taken deeper into ftok and have some questions:
1. Why do you use st_dev explicity. Isn't ftok() only for files ?
>From the ftok documentation:
"The ftok() function returns a key based on path and id that is usable in
subsequent calls to msgget(), semget() and shmget(). The path argument must be
the pathname of an existing file that the process is able to stat()."
So st_dev seems to make no sense for me and could be removed.
2. Does st_ino creates uniq inodes rsp. hash values ? If so, why not (CASE1)
adding an ascii representation of id to the path and calling hash_path_name()
(the function which creates statbuf.st_ino) or (CASE2), using id as hash value
for hash_path_name() like the following code.
key_t
ftok(const char *path, int id)
{
struct stat statbuf;
// call stat() only as file existing check
if (stat(buf, &statbuf))
{
/* stat set the appropriate errno for us */
return (key_t) -1;
}
#ifdef CASE1
char buf[MAX_PATH];
sprintf(buf,"%s%08x",path,id);
return hash_path_name(0,buf);
#else /* CASE2 */
return hash_path_name(id,buf);
#endif
}
This would allow using the current 32 bit key_t implementation.
Ralf