Re: [PATCH] C undefined behavior fix

[Paul Koning]

>>>>> "mike" == mike stump <[e-mail]> writes:

 >> From: [e-mail] To: [e-mail], [e-mail],
 >> [e-mail] Cc: [e-mail],
 >> [e-mail], [e-mail],
 >> [e-mail] Date: Tue, 8 Jan 2002 21:13:43 -0500 (EST)

 >> Yes, of course! No one disagrees. I am talking about *LOADS* not
 >> stores, your example is 100% irrelevant to my point, since it does
 >> stores.

 mike> Ok, in the bodies of those, put in

 mike> j1=c1;

 mike> j2=c2;

 mike> j3=c3;

 mike> With new definitions for j1, j2 and k3 as being volatile.
 mike> Accesses are volatile:

 mike> [#2] Accessing a volatile object, modifying an object,
 mike> modifying a file, or calling a function that does any of those
 mike> operations are all side effects

 mike> So, I would claim that the case is symetric with writing
 mike> volatiles.  If the standard doesn't make a distinction for
 mike> write v read, then you can't and claim that distinction is
 mike> based in the standard.  If you claim the standard does make a
 mike> distinction, please point it out, I am unaware of it.

Ah... so (paraphrasing) -- if you have two byte size volatile objects,
and they happen to end up adjacent in memory, the compiler is
explicitly forbidden from turning an access to one of them into a
wider access -- because that would be an access to both of them, which
is a *different* side effect.  (Certainly that exactly matches the
hardware-centric view of why "volatile" exists.)  And the compiler
isn't allowed to change side effects, including causing them when the
source code didn't ask you to cause them.

So that says that you are indeed entitled to expect the compiler not
to enlarge volatile accesses, neither loads nor stores.  Or, if you
want to be *really* paranoid, you can at least enforce that by
"wrapping" the volatile object, if necessary, with two more volatile
objects that are +1 and -1 address unit away from the one you care
about.  And if the compiler then generates a larger reference, that's
a compiler bug.

Nice.

	paul