On 7/9/06, Pavel Machek <[email protected]> wrote:
Hi!
> Btw, I think that the whole standard definition of "volatile" is pretty
> weak and useless. The standard could be improved, and a way to improve the
> definition of volatile would actually be to say something like
>
> "volatile" implies that the access to that entity can alias with
> any other access.
>
> That's actually a lot simpler for a compiler writer (a C compiler already
> has to know about the notion of data aliasing), and gives a lot more
> useful (and strict) semantics to the whole concept.
>
> So to look at the previous example of
>
> extern int a;
> extern int volatile b;
>
> void testfn(void)
> {
> a++;
> b++;
> }
>
> _my_ definition of "volatile" is actually totally unambiguous, and not
> just simpler than the current standard, it is also stronger. It would make
> it clearly invalid to read the value of "b" until the value of "a" has
> been written, because (by my definition), "b" may actually alias the value
> of "a", so you clearly cannot read "b" until "a" has been updated.
...
> In contrast, the current C standard definition of "volatile" is not only
> cumbersome and inconvenient, it's also badly defined when it comes to
> accesses to _other_ data, making it clearly less useful.
>
> I personally think that my simpler definition of volatile is actually a
> perfectly valid implementation of the current definition of volatile, and
> I suggested it to some gcc people as a better way to handle "volatile"
> inside gcc while still being standards-conforming (ie the "can alias
> anything" thing is not just clearer and simpler, it's strictly a subset of
> what the C standard allows, meaning that I think you can adopt my
> definition _without_ breaking any old programs or standards).
Are you sure?
volatile int a; a=1; a=2;
...under old definition, there's nothing to optimize but AFAICT, your
definition allows optimizing out a=1.
Pavel
--
You don't have to go that far. "Alias with anything" is too vague,
because it basically means that all external variables are volatile if
any are. In the original example, b shouldn't be allowed as an alias
for a, because a is not "volatile". Otherwise, once you've added any
volatile variables you've effectively said "all variables are
volatile".
Anyway, this approach is the opposite of the original intent of
volatile. Originally, the idea was that volatile meant "anything
might have changed b since the last time you referenced it". Here,
you're saying "changing b could change anything".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
