On Wed, 3 Apr 2013, Linus Torvalds wrote: > .. and my argument is that we don't care about paper standards, we > care about QUALITY OF IMPLEMENTATION. > > If a compiler messes up volatile casts, the quality of implementation > is bad. There's just no excuse. > I agreed, and I agreed when we had a "discussion" about the sign of a bitfield six years ago, but the key here is that I'm talking about meaning of the comment and not the compiler. I'm trying to clear up any misconception that people have, and that's why it's a patch that modifies a comment and not source. Those misconceptions exist, like it or not. People have seen this ACCESS_ONCE() abstraction and think they can use it to solve concurrency issues in their own userland code with dereferences to shared objects. > There is no sane alternative semantics to "volatile" that I can come > up with. Seriously. What meaning could "volatile" ever have that would > be sensible and break this? > > Now, I do repeat: I don't like volatile. I think it has many problems, > and being underspecified is just one of them (the much deeper problem > is that the C standard attaches it to the data, not to the code, and > we then have to "fix" that by mis-using it as a cast). > I know you do and I know you contributed to having an entire volatile-considered-harmful doc in the tree, which is really a lecture on C rather than having anything specific to do with the kernel itself. So I'm a little surpised that you wouldn't opt for being 100% explicit in one of its rare appearances. It's easy to see you're no longer amused. > So if some improved standard comes along, I'd happily use that. In the > meantime, we don't have any choice, do we? Seriously, you can talk > about paper standards until you are blue in the face, but since there > is no sane alternative to the volatile cast, what's the point, really? > Would you convert the definition of ACCESS_ONCE() to use the resulting feature from the gcc folks that would actually guarantee it in the compiler-gcc.h files? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>