Re: Possible bug in xfns.c

[Jan D.]

2005-02-26 kl. 15.47 skrev David Kastrup:

> Throwing a signal restores interrupt_input_blocked to the state of the
> recording of the stack frame.

How does it do that?  I can't find that in the code.  I assumed 
record_unwind_protect did just that, recorded one unwind action to 
take.


>   In xfns.c, line 5207, we have a
> BLOCK_INPUT.  In line 5283 we have
>
> record_unwind_protect (clean_up_file_dialog, make_save_value (dialog, 
> 0));
>
> That means that clean_up_file_dialog will get called in case of an
> abort, and x_file_dialog will return with the value of
> interrupt_input_blocked increased by one as opposed to the time of the
> call.

I'm not sure what you mean by an abort.  The only code that does 
something like that is the Fsignal and the unbind_to after the 
UNBLOCK_INPUT.  Are you saying that

  BLOCK_INPUT;
  ...
  record_unwind_protect()
  ...
  UNBLOCK_INPUT;

  unbind_to();

will make interrupt_input_blocked have a value of 1 after the unbind_to 
(assuming it was 0 before BLOCK_INPUT and no code in ... throws)?

> Shouldn't record_unwind_protect be enclosed with
> UNBLOCK_INPUT/BLOCK_INPUT?

That wouldn't be correct, but we could move it before the first 
BLOCK_INPUT.

        Jan D.