svn commit: r208868 - in head/usr.bin: bc dc

[Jilles Tjoelker]

On Sun, Jun 06, 2010 at 04:14:45PM +0400, Andrey Chernov wrote:
> On Sun, Jun 06, 2010 at 03:00:04PM +0300, Kostik Belousov wrote:
> > On Sun, Jun 06, 2010 at 11:36:09AM +0000, Gabor Kovesdan wrote:
> > > @@ -223,14 +222,11 @@ static const struct jump_entry jump_tabl
> > >  	(sizeof(jump_table_data)/sizeof(jump_table_data[0]))

> > >  static void
> > > -sighandler(int ignored)
> > > +got_sigint(int ignored __unused)
> > >  {
> > >  
> > > -	switch (ignored)
> > > -	{
> > > -	default:
> > > -		bmachine.interrupted = true;
> > > -	}
> > > +	putchar('\n');
> > > +	exit(0);
> > >  }
> > In general, calling not async-signal safe functions from the signal
> > handler is an invitation for undefined behaviour, that usually manifests
> > itself as SIGSEGV and SIGBUS.

> Yes, better use write(2) and _exit(2) here.

I wonder if a signal handler is necessary at all here. The shell should
print a newline after an interruption. This does not appear to work in
sh(1) in the (default) interactive job control mode, but works in tcsh,
bash and zsh for example.

Additionally, an exit status of 0 is wrong because a SIGINT abort is not
successful termination. It is best to resend the signal (after setting
it to SIG_DFL and unmasking it) so that it looks like if the signal
handler hadn't been there. Shells may rely on this to distinguish
SIGINTs that caused the command to return to its main loop only and
SIGINTs that aborted the entire command: in the latter case any
enclosing structure should be aborted too.

-- 
Jilles Tjoelker