Date: Mon, 5 Jan 1998 11:00:08 +0200 (IST) From: Eli Zaretskii To: djgpp AT delorie DOT com Subject: Request for comments: SIGQUIT in DJGPP v2.02 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.