What does—or did—"volatile void function( ... )" do?

Question

I've seen How many usage does "volatile" keyword have in C++ function, from grammar perspective? about use of the volatile keyword on functions, but there was no clear explanation of what Case 1 from that question did. Only a statement by one of the respondents that it seemed pointless/useless.

Yet I cannot quite accept that statement, since the AES software implementations for GNUC have been used for literally years, and they have a number of functions like this:

INLINE volatile void functionname( /* ... */ ) {
    /* ... */
    asm( /* ... */ ) // embedded assembly statements
    /* ... */
}

There has to have been a reason for that usage. Can anyone:

A. tell me what the original reason was; and

B. how to achieve the desired effect now?

I'm using Ubuntu, and GCC 4.6.3.

---

Note: The closest I've come to an explanation is that prior to GCC 2.5, you could spoof the 'noreturn' attribute that was implemented in 2.5 via the following:

void fatal( /* ... */ ) { /* ... */ exit(1); }

typedef void voidfn ();

volatile voidfn fatal;

This would allow the compiler to recognize that 'fatal' was not going to return.

But that scenario doesn't appear to apply to the AES code. It's been a long time since I did anything in assembly, but I think I'd recognize a jump or something like that.

Answer 1

According to the gcc documentation (until February 2015), volatile void as a function return value in C (but not in C++) is equivalent to __attribute__((noreturn)) on the function and tells the compiler that the function never returns.

Answer 2

The C99 standard says this in §6.7.3/3:

The properties associated with qualified types are meaningful only for expressions that are lvalues.¹¹⁴⁾

114) The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its address is never used

§6.2.5/19 says:

The void type comprises an empty set of values; it is an incomplete type that cannot be completed.

And §6.3.2.1/1 says:

An lvalue is an expression with an object type or an incomplete type other than void;⁵³⁾ [...]

Hence, void is not an lvalue, so the type qualifiers (const, volatile, and restrict) are not meaningful for expressions of type void. So, in any C99-compliant compiler, const void and volatile void are meaningless (although pointers to const void and const volatile are meaningful).

Furthermore, the constraints of §6.9.1/3 disallow a function to return a qualified type of void:

The return type of a function shall be void or an object type other than array type.

Since this is a constraint, a conforming compiler must issue a diagnostic (§5.1.1.3/1). So a function returning volatile void is not allowed in C99.

As for what volatile void may have used to do, I have no idea and can't really speculate. The AES code you're looking at probably just has old cruft that never got cleaned up, I'd guess.

Answer 3

REFERENCES

• https://github.com/nmoinvaz/minizip/blob/master/aes/aes_via_ace.h See lines 323 through 333, and lines 399 through 492. There are plenty of other places to find this code, this was just the first one I tripped over.

• http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_113.html Thanks @ouah!

• http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-old/binutils-2.18.50/gas/testsuite/gas/i386/padlock.d Turned up on a search for "f3 0f a7", and identifies the opcodes as specialized encryption operations.

• GCC's "info" documentation.

EVIDENCE

• volatile void function(...) is not strictly conforming to C99. (Thanks @Adam and @ouah. @Adam for digging into the C99 spec, and @ouah for pointing me at the DR listed above.)

• GCC added __attribute__((noreturn)) in version 2.5 as a replacement for volatile void, but has continued to accept volatile void as late as version 4.6.3 to support code compatibility with compilers prior to version 2.5. (GCC documentation.)

• The code referenced above does indeed return control to where it was called from, as the instructions do not appear to manipulate the address register(s), nor do they execute a jump command. Instead they load various values into the 32-bit registers. (Code examination.)

• The commands in lines 323 through 333 implement special opcodes in support of encryption operations. (Code examination plus the 'padlock' code.)

• The code using the assembly functions obviously expects them to return. (Code examination.)

• The noreturn attribute tells the compiler that the function does not return, so the compiler can make optimizations based on that. (GCC documentation.)

• From the GCC documentation: Do not assume that registers saved by the calling function are restored before calling the noreturn function.

SOLUTION

It was a discussion with a coworker that finally clued me in. The compiler must do something different when a function declares that it isn't going to return. Examination of the GCC documentation confirmed this.

A. The original reason

You need to ask yourself the following question.

Question: The AES code specifically loads values into the 32-bit registers, and performs operations on them. How does it get the answers back to the rest of the code?

Answer: The GCC optimizations mean that the calling function's registers, which otherwise would have overwritten the values upon return, are not saved. The results of the calculations in the assembly language functions remain in the registers for subsequent code to use.

B. Achieving the desired effect now:

Pretty much leave it alone. The only thing you might do is replace the volatile void return type with simply void, and add the noreturn attribute to the functions. Theoretically, that should have the exact same effect. In practice, it ain't broke, don't fix it.

DESIRABILITY

Extensive use of this technique is definitely discouraged. First, it depends on customization for each compiler. Second, it depends on those compilers not changing how they handle the 'no return' case. Third, it's potentially confusing to subsequent maintainers.

The only situation where something like this makes any sense is when you're taking advantage of highly specialized machine code, to achieve an otherwise impossible improvement in speed. Even then, it should be balanced against the trade-offs.

In this example, precisely two compilers are supported, and only if the machines have the specific hardware support to take advantage of. Otherwise, it's all handled through standard C code. That's a lot of effort. Make sure it's going to pay off before you do it.