Home/ Questions/Q 9175081
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T16:51:23+00:00

I’ve seen How many usage does "volatile" keyword have in C++ function, from grammar

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    REFERENCES

    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.

    • 0