Date: Wed, 31 Oct 2001 09:39:24 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Scheidt <rufus@brain.mics.net> Cc: Nate Williams <nate@yogotech.com>, John Baldwin <jhb@FreeBSD.org>, chat@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <3BE0374C.57ADE54@mindspring.com> References: <Pine.BSI.4.20.0110311007290.25112-100000@brain.mics.net>
next in thread | previous in thread | raw e-mail | index | archive | help
David Scheidt wrote: > > Actually, there are situations where you _must_ use volatile > > to prevent register optimization of variables. > > That's a compiler problem, not a language feature. I guess you weren't hanging out in comp.lang.c back in the very early 1990's, when we discussed this to death, and I came down against ANSI C, everyone jumped down my throat, and Dennis Ritchie himself came down on my side of the argument (it is totally cool to have something like that happen). Here is a pointer to a copy of the posting (article 7844): http://www.lysator.liu.se/c/dmr-on-noalias.html And here is what he says about "volatile": `Volatile', in particular, is a frill for esoteric applications, and much better expressed by other means. Its chief virtue is that nearly everyone can forget about it. Here's an esoteric application: static int exit_at_earliest_convenience = 0; sighandler() { exit_at_earliest_convenience = 1; } ... somefunction() { if (exit_at_earliest_convenience) exit(1); ... if (exit_at_earliest_convenience) exit(3); ... for( i =0; i < 5 && exit_at_earliest_convenience == 0; i++) { ... } ... } The compiler is perfectly _allowed_ by X3J11 (ANSI C) to assume that the value of "exit_at_earliest_convenience" will not change as the result of an asyncronous event, and promote it to a register. This means that when the async event happens, it doesn't matter that the value in memory will change, since the value in the register has not, and therefore the loop will not exit as a result of getting the signal. There are other examples, but this one is one of the easiest. If you manually unroll the loop into an assignment, a "goto" lablel, an "if" test", and an "i++;" followed by a "goto", the problem goes away, because the reason for the promotion goes away. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BE0374C.57ADE54>