bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistency in attribute.c


From: Alain Magloire
Subject: Re: Inconsistency in attribute.c
Date: Mon, 2 Jul 2001 11:39:37 -0400 (EDT)

Bonjour,

> > 
> > BTW, the way we handle SIGINT, will not work quite right.
> > The problem is that libreadline set signal handlers for SIGINT, SIGQUIT
> > and SIGWINCH.  For certain version of readline, you'll have to disable
> > it.  A little annoying since it has to work also without HAVE_READLINE.
> 
> I have checked the stuff with readline 4.1, its signal handler

Ha!

> passes the signal on to the application-defined handler correctly.  
> Do you have some info about which versions of readline do not handle

Not really, I'm working on my "old"  GNU/Linux box RedHat 5.1:
ls -l /usr/lib/libreadline.*
/usr/lib/libreadline.a
/usr/lib/libreadline.so -> libreadline.so.3.0
/usr/lib/libreadline.so.3 -> libreadline.so.3.0
/usr/lib/libreadline.so.3.0                                    

Which seems to indicate readline-3.x, I do not think, in earlier then
4.x the bits to handle user signal handlers were in, libreadline
would just take over.  Unless you rl_clear_signals() and do in
the signal handler the work for readline:,

void sig_int (int signo)
{
...
        rl_free_line_state ();
        rl_cleanup_after_signal ();
..
        // longjmp (jmbuf, 1);  /* jump out to a know state.  */
}

I think, it will be necessary to this, if we decide to use setjmp()'s and
longjmp() out from the signal handler,  when cntl-C is sent while
executing command like retrieving headers "from *" or downloading messages.
Relying on errno == EINTR and unwinding the stack may not be possible
which leave us to longjmp(), I do not know if even readline-4.1 handle
this well.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]