Mail Archives: djgpp/1998/01/05/04:04:10
A change to support the signal SIGQUIT which is currently planned for
the next release 2.02 of DJGPP might have unexpected effects on some
programs.
Below I describe some aspects of this change, and what kind of programs
might be affected by it. I would like to ask people who know about
programs that could be burnt by this change to please name these
programs and describe in a few sentences the way these programs
read the keyboard, and how hard would it to change the program to be
compatible with this change (the necessary changes are described
below). It doesn't matter whether the program is your own or from
some package written by somebody else.
Even if you don't have a particular program as an example, but can
imagine a program that can reasonably do something that will make
trouble when v2.02 is released, please describe your case and tell
what do you think.
One of the aspects I would like to hear about is the effect of this
change on user interface libraries such as Curses and Allegro and on
programs which use those libraries.
This information is important for getting the change right. Thanks in
advance for any help!
---------------------------------------------------------------------
SIGQUIT is a signal that is supported on Unix systems and is also part
of the POSIX spec. On Unix, this signal is generated by pressing
Ctrl-\ and the default action associated with it is to abort the
program.
Current versions of DJGPP know about SIGQUIT, but it cannot be
generated by a keypress. This makes it difficult to port programs
that catch SIGINT and SIGQUIT differently.
For the next DJGPP release, it is planned to add the ability to
generate SIGQUIT like Unix does. When DJGPP v2.02 is out and programs
are rebuilt with it, pressing Ctrl-\ key will kill the program unless
it takes necessary precautions (e.g., installs a SIGQUIT handler or
disables SIGQUIT generation). If a program already uses Ctrl-\ for
other purposes, that program will break.
Before you get mighty mad about those DJGPP gurus who keep breaking
your programs with every release, let me say right here that I believe
this problem to be largely non-existent in practice. Here's why:
1) Programs which need to read keys such as Ctrl-\, usually
switch stdin to binary mode, because otherwise single keys
cannot be read easily, and because some keys, like Ctrl-C or
Ctrl-S, are interpreted by DOS. Switching stdin to binary
mode disables both SIGINT generation by Ctrl-C, and it will
disable SIGQUIT generation by Ctrl-\ in v2.02. The effect of
calling "__dpjpp_set_ctrl_c(0)" will be to prevent both Ctrl-C
and Ctrl-\ from generating the signals.
So programs which switch stdin to binary mode and/or call
`__dpjpp_set_ctrl_c' to disable SIGINT are safe.
2) Programs which are ported from Unix and need to read Ctrl-\
verbatim, already take the necessary precautions in their
original code, so these will be also safe.
3) Programs which install a hardware keyboard interrupt handler
to read the keys are also safe, since they see Ctrl-\ before
the DJGPP handler that generates SIGQUIT.
The only programs that will be affected are those who read their input
either through DOS in text mode, or through the BIOS interrupt 16h,
*and* bind Ctrl-\ to some action. The question is: how many such
programs exist today? If the answer is "none", then the problem
doesn't exist, and SIGQUIT can be safely added to DJGPP.
If there *are* some programs like this, fixing them shouldn't be hard.
You have two possible ways of doing that:
- define a signal handler for SIGQUIT;
- disable SIGQUIT generation by calling a function that will be
part of v2.02.
Finally, there's a possibility of making SIGQUIT in v2.02 disabled by
default at startup, and enabling it only when one of the functions
that catch SIGQUIT are first called by the program. This solution
seems like the best of both worlds, but implementing it is tricky and
might have some subtle bugs/features which I'd like to avoid unless
they are absolutely necessary. I'd like to hear opinions about this
option also.
Once again, thanks to everybody who participates in this discussion,
even if you only take the time to read this longish message.
- Raw text -