lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev CTRL/C behavior in new version ...


From: Klaus Weide
Subject: Re: lynx-dev CTRL/C behavior in new version ...
Date: Tue, 2 May 2000 11:18:21 -0500 (CDT)

On Mon, 1 May 2000, Jerome LAURET wrote:

>       I think that there is a missfeature. Whenever I use CTRL/C, I do have
> the "Really exit from Lynx (y) ?" question poping-up but regardless of what
> I would answer, I always have the session resuming to it's current operation.
> That's a bit bothering ... 
>       Is this seen on other platform ? (btw : independant of Slang).

This cannot appear on other platforms than VMS:  the prompt in
response to ^C is implemented only for VMS, on other platforms ^C
exits immediately (if it doesn't get completely ignored).  It isn't "safe"
to call I/O functions from interrupt handlers (I don't know why VMS gets
away with it).

There seems to be a problem in the logic in cleanup_sig (LYClean.c) in
connection with HTConfirmDefault (HTAlert.c).  (This code changed since
2.7.1 or thereabouts.)

Exhibit A:
----------------------------------------------
PUBLIC void cleanup_sig ARGS1(
.....
#ifdef VMS
    if (!dump_output_immediately) {
.....
        HadVMSInterrupt = TRUE;
.....   ^^^^^^^^^^^^^^^^^^^^^^   !!!
        /*
         *  Ask if exit is intended.
         */
        if (LYQuitDefaultYes == TRUE) {
            c = HTConfirmDefault(REALLY_EXIT_Y, YES);
        } else {
            c = HTConfirmDefault(REALLY_EXIT_N, NO);
        }
.....
----------------------------------------------

Exhibit B: (some comments added)
----------------------------------------------

PUBLIC int HTConfirmDefault ARGS2(CONST char *, Msg, int, Dft)
{
.....
        while (result < 0) {
            int c = LYgetch_for(FOR_SINGLEKEY); /* does not set or modify
                                                   HadVMSInterrupt */
#ifdef VMS
            if (HadVMSInterrupt) {
                HadVMSInterrupt = FALSE;
                c = *msg_no;             /* !!! */
            }
#endif /* VMS */
.....
----------------------------------------------

So HTConfirmDefault would always return NO, when called in this
situation.

Deferring the  'HadVMSInterrupt = TRUE;'  until after the HTConfirmDefault
calls should solve the problem, but I have no way of testing for VMS.

Btw., you should have mentioned that you are talking about VMS; don't
expect folks to remember that from your other messages (even if they where
just a short while ago).

   Klaus


reply via email to

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