Explicit
+casting in atomic_read() ensures consistent behavior across
architectures
+and compilers.
Even modulo compiler bugs, what makes you believe that?
When you declare a variable volatile, you don't actually tell the
compiler where you want to override its default optimization behavior,
giving it some freedom to guess your intentions incorrectly. When you
put the cast on the data access itself, there is no question about
precisely where in the code you want to override the compiler's
default optimization behavior.
...except for the small point that this isn't how volatile works.
Rule of thumb: even people who know the semantics of volatile
shouldn't use it.
If the compiler doesn't do what you want with a volatile declaration,
it might have a plausible excuse in the ambiguity of the C standard.
If the compiler doesn't do what you want in a cast specific to a
single dereference, it's just plain broken.
The other way around. "volatile" has pretty weak semantics, and
certainly not the semantics you think it has, or that you wish it
had; but *(volatile XX *) doesn't have *any* semantics. However
much you cast that pointer it still doesn't point to a volatile
object.
GCC will generally take the path of least surprise and perform a
volatile access anyway, but this has only be decided recently (a
year ago or so), and there very likely still are some bugs in
that area.
We try to be compatible with plausibly correct compilers, but if
they're completely broken, we're screwed no matter what.
If you don't know what to expect, you're screwed for sure.
Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object? That you can access that same object in
a non-volatile way?
Segher
-
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]
