From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1705 invoked by alias); 18 Jul 2005 15:47:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1638 invoked by uid 22791); 18 Jul 2005 15:47:14 -0000 Received: from gw-d.mimosa.com (HELO gw-d.mimosa.com) (216.126.78.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 18 Jul 2005 15:47:14 +0000 Received: from redshift.mimosa.com (redshift.mimosa.com [192.139.70.107]) by gw-d.mimosa.com (8.12.8/8.12.8) with ESMTP id j6IFl9OE022997; Mon, 18 Jul 2005 11:47:09 -0400 Date: Mon, 18 Jul 2005 15:47:00 -0000 From: "D. Hugh Redelmeier" Reply-To: "D. Hugh Redelmeier" To: Paul Schlie cc: Gabriel Dos Reis , gcc@gcc.gnu.org Subject: Re: volatile semantics In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-07/txt/msg00790.txt.bz2 | From: Paul Schlie | > | void foo(void) { | > | int *x = 4; | > | *x = 3; | The point I was attempting to make, was that just because a specified | statement's effective behavior/side-effects are not well defined, it doesn't | mean that it's clearly specified semantic actions may be summarily ignored. The Standard specifically allows an implementation a lot of choices when dealing with "undefined behavior". Quoting n1124.pdf: 3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous for which this International Standard imposes no requirements NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic environment (with or without the issuance of a diagnostic message), to terminating a translation execution (with the issuance of a diagnostic message). EXAMPLE An example of undefined behavior is the behavior on integer overflow. I think (but am not 100% sure) that this example falls into the category of "undefined behavior". Certainly the earlier example does. So the implementation is free to do pretty much anything at all to the program as a whole (for example, refuse to compile it) just because a part of it invokes "undefined behavior". Even though the NOTE does not call this out, the implementation may do completely unreasonable things -- the committee felt that it could not actually require anything of an implementation when dealing with "undefined behavior". Hence the wording "imposes no requirements" (but note that the sense of that phrase in context is subtle). The effect is no way prevented from changing the behaviour of things that are well defined (the undefinedness bleeds through to the whole program). Not all Bad Things are categorized as "undefined behavior". Let's think about your concrete example. That assignment might (on a reasonable implementation) curdle an interrupt vector. Which might have almost any effect on the execution of the program. Including apparently retroactive effects. Certainly effects that cannot be explained in the abstraction that is the C Standard + implementation-supplied documentation mandated by the Standard. No wonder that the Standard throws up its hands. [Sorry to be so long winded. I think that being more concise would enable more misunderstanding.]