bug#32375: Bug Gzip v1.9

[Antonio Diaz Diaz]

Paul Eggert wrote:
> Thanks for reporting the bug. Although I doubt whether it can occur on
> any practical platform, we should fix it even if it's just theoretical.

I have applied to lzip a change similar to yours, but I'm not sure it 
fixes the theoretical problem.


> +static char volatile remove_ofname[MAX_PATH_LEN];

I see two problems with this fix. The first is that it limits filename 
size. It seems that on GNU/Hurd systems there is no limit to the size of 
a file name, so this would place an artificial limit to the use of lzip 
on such systems.

The second is that posix states the following:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03
------------------------------------------------------------------------
If the process is multi-threaded, or if the process is single-threaded 
and a signal handler is executed other than as the result of:
  * The process calling abort(), raise(), kill(), pthread_kill(), or
    sigqueue() to generate a signal that is not blocked
  * A pending signal being unblocked and being delivered before the
    call that unblocked it returns

the behavior is undefined if the signal handler refers to any object 
other than errno with static storage duration other than by assigning a 
value to an object declared as volatile sig_atomic_t, or if the signal 
handler calls any function defined in this standard other than one of 
the functions listed in the following table.
------------------------------------------------------------------------

The last paragraph seems to imply that a signal handler can't read any 
static object, only write to 'volatile sig_atomic_t'. This is how I 
implemented the Ctrl-C handler in ddrescue, but in the case of gzip and 
lzip, polling a sig_atomic_t variable may be inefficient or cause a 
noticeable delay. I find posix too restrictive in this respect.

Any thoughts?


Antonio.