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
--
Thanks for all the (sleeping) penguins.
-
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]
