13

This is basically a continuation of this question. So far it looks like that if I have a function like this:

void SecureZeroMemory( void* ptr, size_t cnt )
{
   volatile char *vptr = (volatile char *)ptr;
   while (cnt) {
       *vptr = 0;
       vptr++;
       cnt--;
   }
}

and call it like this:

{
    char buffer[size];
    SecureZeroMemory( buffer, size );
}

then since buffer is not declared volatile it doesn't matter that a pointer to volatile is used - the data itself is not volatile, so write to the variable do not constitute observable behavior (1.9/6) and the compiler is allowed to optimize them away.

However recently I've come across a statement that it's only the pointer declaration that matters. Specifically C++03 5.3.1/1 describes indirection (*) like this:

The unary * operator performs indirection [...] If the type of the expression is “pointer to T,” the type of the result is “T.”

So the claim is that because of using indirection on a volatile char* we get volatile char and writes to those do constitute observable behavior and it no longer matters how the actual data is declared.

Does the C++03 5.3.1/1 description of indirection really guarantee that overwriting memory using a volatile T* pointer as in the sample above constitute observable behavior and is disallowed to be optimized away?

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979

2 Answers2

4

I'm pretty sure all that "new" quote adds is that *vptr is an lvalue expression with type volatile char.

The type of the lvalue doesn't affect the type of the object to which that lvalue expression refers, for the same reason that a pointer-to-const that points at a non-const object doesn't somehow make the object const. So the original analysis isn't affected this quote -- the object still doesn't have volatile-qualified type.

In normal parlance we'd say that the type of *vptr is volatile char &, but 5/5 says, "If an expression initially has the type “reference to T” the type is adjusted to T prior to any further analysis". That's the reason why *vptr is said to have type volatile char, not volatile char & -- before analysing any expression you remove the reference from the type, even if it's an lvalue.

[Edit: my answer used to have some text about cv-qualifications being insignificant for non-object values of integer type. It was true (lvalue-to-rvalue conversions of non-class types discard cv-qualifiers, 4.1/1) but irrelevant (I mistakenly thought that because the text you quoted mentioned a non-reference type it was talking about the type after this conversion)]

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • @LightnessRacesinOrbit: sorry. Done now. – Steve Jessop Dec 06 '12 at 14:54
  • Good now I can walk away without guarding my upvote against any more incremental changes I might disagree with ;p – Lightness Races in Orbit Dec 06 '12 at 14:54
  • Well, a pointer to const says the object can't be changed through that pointer, so for example the compiler is allowed to optimize away sequential reads through the same pointer, isn't it? In this sense the object becomes const for the code that accesses it through a pointer to const. – sharptooth Dec 06 '12 at 15:00
  • @sharptooth: Not exactly. Consider `int func(const int &a; void(*f)()) { int result = a; f(); return result + a; }`. The compiler is *not* permitted to assume that `a` isn't modified by the call to `f`. If it somehow knew that `a` referred to a const object then it could assume that. So there's a significant difference between a const object, and an object referred to by a const-qualified reference. Const-qualified references are pretty much useless for optimization. If it can see what `f` points to and what the code does, then it can deduce whether `a` changes or not regardless of `const`. – Steve Jessop Dec 06 '12 at 15:03
  • Or also consider `int func(const int &a, int &b) { ++b; return a; }`. Again, the const-qualification of `a` doesn't permit the compiler to read the value of `a` before incrementing `b`. [Edit: sorry, changed the example when I realised the old one had potential UB anyway]. I don't have multiple reads of `a` here, just one, but if I did have reads before and after `++b` I couldn't optimize them to a single read without first establishing that `a` and `b` refer to different objects. If I could establish that they refer to different objects, I could do a single read even if `a` wasn't const. – Steve Jessop Dec 06 '12 at 15:07
  • Well, I looked moar and found this in C++03 3.9.3/1: *The cv-qualified or cv-unqualified versions of a type are distinct types* which looks contradicting the idea that cv-qualifiers are ignored for all practical purposes. – sharptooth Dec 06 '12 at 15:20
  • @sharptooth: I accept that they're different types, I'm talking specifically about expressions whose result has a (cv-qualified) non-class-type. – Steve Jessop Dec 06 '12 at 15:22
  • @sharptooth: C++11 4.1/1: "A glvalue of a non-function, non-array type T can be converted to a prvalue ... If T is a non-class type, the type of the prvalue is the cv-unqualified version of T". Also 5/5: "If an expression initially has the type “reference to T” the type is adjusted to T prior to any further analysis". So what I said is wrong, I'll correct it. – Steve Jessop Dec 06 '12 at 15:27
  • I don't quite get this conceptual difference between lvalues and objects. I always thought I can access objects using rvalues and lvalues only so their types should matter, but here it looks like it only matters what the object type is. – sharptooth Dec 07 '12 at 07:23
  • @sharptooth: an lvalue is an expression. An object is a region of memory. The type of a variable is what the object was defined as, so an lvalue that's just the name of a variable has the same type as the object it designates (prior to array decay etc). Other lvalue expressions might have different type from the type of the object they designate. 3.10/10 defines which types an object can be accessed through. – Steve Jessop Dec 07 '12 at 10:58
4

It's an interesting question. I think the intent of the standard was that this should work. On reading the standard (C++03, §1.9/6,7) however:

The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions.

Accessing an object designated by a volatile lvalue, modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression might produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

The difference in wording in the two paragraphs would seem to be significant: the "observable behavior" is the sequence of reads and writes volatile data. In your case, buffer is not volatile data, so the compiler is, presumably, free to optimize the accesses away. I don't think that this is the intent, but that seems to be what it says.

In your case, the optimization would be particularly simple, since the conversion to volatile occurs in the function itself. The compiler can easily determine that vptr doesn't point to data that is actually volatile. If you change the parameter type to void volatile*, then the compiler would have to see both the call site and the function at the same time in order to safely do the optimization.

And finally, regardless of what the standard says, compilers have their own interpretations of volatile. In practice, most, if not all compilers, will assume that you are using volatile for a reason, and will generate the machine instructions to do the writes. (In practice, that is all that they will do, which means that the order that the writes become visible outside of the thread the code in which the thread is running remains undefined. This isn't a problem for your use, but it is for a lot of other uses.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329