This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]