RE: MIT shared memory extension

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

> 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