www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/13/09:41:30

Date: Tue, 13 Jan 1998 14:38:20 +0000 (GMT)
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Request for comments: SIGQUIT in DJGPP v2.02
In-Reply-To: <Pine.SUN.3.91.980113105515.5496K-100000@is>
Message-ID: <Pine.OSF.3.95.980113143338.24898D-100000@sable.ox.ac.uk>
MIME-Version: 1.0

On Tue, 13 Jan 1998, Eli Zaretskii wrote:

> The above is all that's needed to turn on SIGQUIT generation.  I
> wanted to avoid even a single line if it isn't necessary.  However,
> the few replies that I got seem to indicate that this issue is
> somewhat controversial, and DJ is uneasy about enabling it by
> default.  So it seems like SIGQUIT will by default be ignored (i.e.,
> its SIG_DFL action will be to just return), and applications that need
> it will have to turn it on by calling `signal' with a non-default
> handler.

If the user doesn't want Ctrl-\ to abort their program, wouldn't it be
easier to leave SIGQUIT respected but ignore the keypress, rather than
process the Ctrl-\ keypress, generate a SIGQUIT and have it just do
nothing?  It seems to me that the dangerous thing is Ctrl-\ generating the
signal in a program which doesn't want that to happen, not the signal's
existence in the first place.  Shouldn't a program be able to raise the
signal artificially if it wants to?

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019