> This is off-topic for the xfree mailing list, it's really a developer or > general topic. Anyway....
Should we move this to the cygwin list ? I'm not subscribed to the develop list. > > 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. > > Possibly. If the file can be stat'd - and devices can - we should check > it, no? Yes, this can be done after the stat() call. > > 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. > > hashs collide. key_t's can not collide under any circumstance, and must > be deterministic (i.e. not dependent on currently issued keys). But how do you ensure this in the current implementation ? st_ino contains a hash value. So this problem concerns the current implementation and the suggestion I've made. > > How do you suggest that you avoid hash collisions? With my suggestion I haven't adressed the problem of avoiding hash collisions. I only have addressed the newlib patch you suppose. Sorry :-( BTW: I have additional looked into the cygipc implementation. They uses only the lower word of st_ino and lowest byte of st_dev and lowest byte of id. And this seems to work, although the must have this hash collision problem even more, doesn't it ? May be this is another way to prevent the newlib patch. Regards Ralf