posix says: Only the low-order 8-bits of id are significant. The behavior of ftok() is unspecified if these bits are 0. #if APR_USE_SHMEM_SHMGET static key_t our_ftok(const char *filename) { /* to help avoid collisions while still using * an easily recreated proj_id */ apr_ssize_t slen = strlen(filename); return ftok(filename, (int)apr_hashfunc_default(filename, &slen)); } #endif If you get unlucky the default hash function can return values that hit the unspecified case, on my nightly test system this happens occasionally based on the parent pid of of httpd, here is an unlucky one: /tmp/httpd_lua_shm.66808 Which hashes to 1477165056 0b1011000000010111100000000000000 Would even a minor change to our_ftok() require a release boundary to be changeable when APR is not embedded?
We changed from plain ftok() to our_ftok() in 1.5 so should be fine to fudge it IMO. Is there any platform where ftok actually misbehaves when passed 0? IIRC most implementations simply XOR the inode number with the project ID
This was changed from a constant to a hash across the filename because the bug below that points to NOTES in the linux/glibc manual that says separate filenames with the same low 16bits in the inode can collide too. https://bz.apache.org/bugzilla/show_bug.cgi?id=53996 Collided with Joe: Yes, we see it fail w/ EINVAL on z/OS.
fall back to 1 if the ID looks suspicious? http://people.apache.org/~covener/patches/pr64746.diff
+1 from me