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
