GNU bug report logs - #32375
Bug Gzip v1.9

Previous Next

Full log

View this message in rfc822 format

From: Antonio Diaz Diaz <antonio <at> gnu.org>
To: Johannes Przybilla <johannes.przybilla <at> rwth-aachen.de>
Cc: 32375 <at> debbugs.gnu.org, Bdale Garbee <bdale <at> gag.com>
Subject: bug#32375: Bug Gzip v1.9
Date: Wed, 08 Aug 2018 13:12:04 +0200

Johannes Przybilla wrote:
> I agree that the POSIX standard is quite restrictive in this
> respect. However I believe that is for a good reason. Performing
> non-atomic memory operations on static objects in a signal handler
> can cause problems with reentrancy. This can lead to undefined
> behaviour for example in the case of nested signal handler calls that
> update the same static object.

This is not at all the case in gzip and gzip-like compressors. In them 
the handler is executed just once to perform some cleanup operations 
(mainly remove the partial output file), an then exit. The handler does 
not perform any non-atomic memory operations on static objects, and 
control never returns to the main thread. IMO posix should allow to this 
kind of cleanup handlers read access to any static object.

In fact, as Paul pointed out, any practical platform probably allows 
such read access because many of the functions posix allows to be called 
from a handler require a filename, which in the case of a cleanup 
handler is most probably a static object.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.