Jan Vroonhof wrote:
> > > -D_USE_BSD?)
> >
> > Could it be that for some reason using this flag in the application
> > breaks the library too?
>
> Well, it won't cause libgpm to start using BSD signal semantics.
> However, libgpm reinstalls the old handler with signal(), which may
> not be the same version of signal() that the handler was designed to
However in XEmacs case this handler is SIG_DFL. Is this also
specialcased in the libc5 include files? I.e. is there a sysv SIG_DFL
and a BSD SIG_DFL?
No. They are always as follows:
#define SIG_DFL ((__sighandler_t)0) /* default signal handling */
#define SIG_IGN ((__sighandler_t)1) /* ignore signal */
#define SIG_ERR ((__sighandler_t)-1) /* error return from signal */
This problem is also solved by using sigaction right?
The problem of libgpm assuming that signal() has SysV semantics would
be solved by using sigaction().
However, if the problem also exists in libc-5 versions of libgpm (and
isn't caused by __USE_BSD_SIGNAL or __FAVOR_BSD getting defined), then
sigaction() won't help.
Also, libgpm probably needs to use the entire `struct sigaction' which
is returned in the third argument to sigaction(), not just the
sa_handler field. If libgpm reinstalls the old sa_handler with the
wrong sa_flags and/or sa_mask, the results could be unpredictable.
--
Glynn Clements <glynn(a)sensei.co.uk>