[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