> The point is that the implementation of a write has, given your
> quote from the RM, pretty much no choice but to do an exactly
> "correct" write, but for a read, there is nothing to stop reading
> MORE than the minimum, the requirement of atomicity is still
> met.
Ok, we can agree the wording in the standard sucks. Though, I think
we might be able to agree on the intent and goal of the wording. It
isn't allowed to mandate the byte read/write, as the machine may not
support it, and that would artificially constrain the machine from
being implementable on the platform, and this would be a bad idea.
I think the goal and intent, for Ada and C as well, is to say that the
compiler will generate what is possible from assembly code written by
an expert on the platform, using the best fitting access that is
possible.
Once we understand the standard and the motivation behind it, and what
it is trying to provide our users, and how our users might reasonably
use it, we can mandate for ourselves as a quality of implementation
issue, if you would like to call it that, those reasonable semantics.
Should we fail to provide them, and should users want them, then it is
finally up to the users to more completely describe the language they
want, and refine the language standards to include it. But, in spite
of that, we don't have to go out of our way to do stupid things, nor
should be brow beat our users with, your code isn't conformant
needlessly. It is all to easy to do that, we should resist the
temptation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/