> The definition of key_t in newlib is a 32bit int, for cygdaemon it needs > to be 64 bit to store the inode and the index cleanly. Redefining that > will break every cygipc linked application when they are rebuilt, until > cygipc is rebuilt against the new source. However rebuilding cygipc will > break every already linked app. So until the cygdaemon shm code is > complete, Chuck and I figured that it was not worth putting everyone > through the agony of a backwards incompatible ABI change. > What about using a new type respective casts for cygdaemon. This would not break key_t compatibility and allows to migrate single application to cygdaemon, while others works with cygipc (at least for a limited time) ?
./include/sys/types.h:typedef long key_t; What about interpreting key_t as "pointer to shm_key_t" or something else ? Okay, this causes to support an internal list of shm_key_t elements :-( But when I see right, you have to maintain already such a list class shmnode { public: class shmid_ds * shmds; int shm_id; class shmnode *next; + shm_key_t key; - key_t key; HANDLE filemap; HANDLE attachmap; class _shmattach *attachhead; }; The interfaces of the relates functions could be used as before, only the interpretation is changed. key_t ftok(const char *, int) { ... return &node->key; } int shmget(key_t key, size_t, int); ... shm_key_t *akey = (shm_key_t *)key; ... What do you mean, could this be a workable solution ? Ralf