minow@decvax.UUCP (Martin Minow) (12/14/86)
This is one of a collection of comments on the Draft Standard, posted to comp.lang.c for discussion before I mail a final draft to the Ansi C committee. Each message discusses one problem I have found with the Draft Standard that I feel warrants a "no" vote. Note that this message is my personal opinion, and does not reflect on the opinions of my employer. ---- Problem: Page 202, line 46ff. volatile objects will have indeterminate values if longjmp() is called ``in contexts of signals, interrupts, and any of their associated functions.'' ---- Motivation: If longjmp() is called from a signal handler, volatile objects may have indeterminate values as they cannot always be updated by atomic (one machine cycle) operations. It is unrealistic to require an implementation to lock interrupts before modifying a volatile object. The Standard should note that volatile objects are indeterminate when longjmp() is called from an interrupt or signal handler. I would suspect that, in some implementations, longjmp() cannot be called from interrupt or signal handlers. I would recommend that this capability be regarded as implementation-dependent. ---- Martin Minow decvax!minow
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/15/86)
In article <111@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >I would suspect that, in some implementations, longjmp() cannot be called >from interrupt or signal handlers. You may be right. I actually argued that there was nothing whatsoever that could be guaranteed for signal handlers, including executing anything whatsoever. I would like to hear from anyone who KNOWS for sure that longjmp() canNOT be implemented on some reasonable machine so that it can be safely invoked from a signal handler.