bug-gzip
[Top][All Lists]
Advanced

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

bug#32375: Bug Gzip v1.9


From: Antonio Diaz Diaz
Subject: bug#32375: Bug Gzip v1.9
Date: Wed, 08 Aug 2018 13:12:04 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14

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.





reply via email to

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