Allen Briggs wrote:

> This does not appear to be the entire story, but I've not looked
> much at this code before.  There appears to still be some dependence
> on SEMUSZ in SEMU(ix), which are defined as
> 
> #define SEMU(ix)        ((struct sem_undo *)(((long)semu)+ix * SEMUSZ))
> #define SEMUSZ  (sizeof(struct sem_undo)+sizeof(struct undo)*SEMUME)
> 
> I think there may also be some handling of the "undo structure
> pool" when the # of undos is dynamically increased by changing
> seminfo.semume.

It appears that seminfo.semume isn't changable (unless you mean changing
it with say gdb --write).  I think the original patch in the PR has the
right effect otherwise.  That said, it looks like changing SEMU to use
seminfo.semume instead of SEMUME would be a good idea.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/