C undefined behavior fix
Quoted 9 lines
From: [email protected]
To: [email protected], [email protected], [email protected]
Cc: [email protected], [email protected], [email protected],
[email protected]
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.
Ok, in the bodies of those, put in
j1=c1;
j2=c2;
j3=c3;
With new definitions for j1, j2 and k3 as being volatile. Accesses are volatile:
[#2] Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects
So, I would claim that the case is symetric with writing volatiles. If the standard doesn't make a distinction for write v read, then you can't and claim that distinction is based in the standard. If you claim the standard does make a distinction, please point it out, I am unaware of it.
Quoted 10 lines
Quoted 10 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
"mike" == mike stump <[email protected]> writes:
From: [email protected] To: [email protected], [email protected], [email protected] Cc: [email protected], [email protected], [email protected], [email protected] 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