Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!mit-eddie!genrad!decvax!minow From: minow@decvax.UUCP (Martin Minow) Newsgroups: comp.lang.c Subject: ANSI C -- longjmp and volatiles Message-ID: <111@decvax.UUCP> Date: Sun, 14-Dec-86 11:16:09 EST Article-I.D.: decvax.111 Posted: Sun Dec 14 11:16:09 1986 Date-Received: Tue, 16-Dec-86 02:15:28 EST Lines: 29 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