Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.erje.net!news2.arglkargh.de!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.programming.threads,comp.unix.programmer Subject: Re: Safe accesses of global arrays in signal handlers? Date: Tue, 25 Sep 2012 13:27:52 +0100 Lines: 23 Message-ID: <877gri8eyf.fsf@sapphire.mobileactivedefense.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net icYj2HehOGaFNmvzVxll6A1aiKSFOzKuotiINunOqhupNCiuMK8rnh24ur3GVA8LQ= Cancel-Lock: sha1:dTxCFp8hVuUo8rtucLc0yYbt6BI= sha1:SCQZUA/ZiAaUiI9u84JinqBVOW8= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: csiph.com comp.programming.threads:1091 comp.unix.programmer:3315 Markus Elfring writes: > A secure programming guideline contains the following information. > > https://www.securecoding.cert.org/confluence/display/seccode/SIG31-C.+Do+not+access+or+modify+shared+objects+in+signal+handlers > : > 'Accessing or modifying shared objects in signal handlers can result in race > conditions that can leave data in an inconsistent state. The exception to this > rule is the ability to read and write to variables of volatile sig_atomic_t. > ... > It is important to note that the behavior of a program that accesses an object > of any other type from a signal handler is undefined.' ... by any/ most applicable C standards. 'For security' it is recommended that all programs are written in strictly conforming ISO C. Since this means they usually won't do anything useful, nobody will ever run them and everybody is perfectly 'secure'. Prior to C11 (as far as I have heard) atomicity (or lack thereof) of memory accesses is a feature of the target platform and the usual way to determine what kind of memory accesses are or aren't atomic would be to consult the applicable documentation. Which is not 'a C standard' but some kind of ABI document.