Misnomers in C

C has many misnomers concerning keywords. Here I give a table of possible keywords and convenient macro names that might replace them. New keywords in future C standards usually start with an underscore and a capital letter. Macros in new header files may be just convenient names. (For an example take the inclusion of _Bool and bool into C99).

This is not completely serious, but it might give you an idea of the different concepts. It also should emphasize the fact that none of these keywords is ignored by a conforming C compiler. If you have any ideas of other keywords or other possible namings, please let me know.

keyword/macro replacement macro comment
and_eq &= and_assign is an assignment not a comparison
const _Immutable immutable
_Invariant invariant
char _Byte byte in combination with signed and unsigned
inline _Negligible negligible
or_eq |= or_assign is an assignment not a comparison

_Addressless addressless


_Intern intern for use in file scope
_Common common for use in function scope
_Atleast atleast for use in parameter declaration. A similar proposal was rejected by the standards committee
typedef _Typealias typealias Doesn’t define a type
union _Overlay overlay
unsigned _Modulo modulo unsigned integers just implement computation modulo a power of 2
xor_eq ^= xor_assign is an assignment not a comparison

Edit: I changed

  • once to common, because this reflects better that this is a variable that is common to all invocations of a function.
  • synonym to typealias, to stay closer to the original

12 thoughts on “Misnomers in C”

  1. Your alternative names are spot on, and accurately separate the “real meanings” of the various uses of the keywords. Fortunately I’ve never seen any conflicts where the same keyword needs to be used for different purposes in the same place, however I do quite dislike the way static/inline work. I am confused about _Once, in what circumstance is static used for this? Does this refer to a single evaluation of the RHS to a function scope static variable?

  2. Yes, I think at least they took care that the meaning of each of these
    keywords may be deduced from the context.

    With _Once I actually meant the same thing as _Notauto, just to
    emphasize on the fact hat such a variable is allocated and initialized
    only once. Perhaps not such a brilliant naming, either 😉

    If you have different ideas for some of the uses, let me know.

  3. A few niggles:
    • “Unmutable” should be “immutable”;
    • Neither “immutable” nor “invariant” (nor “const”, for that matter) tell the right story when used in parameter lists, and neither is much of an improvement over “const” when used for a variable declaration;
    • Is “addressless” really better than “register”? I don’t want an “addressless” variable but a “fast-to-access” one—i.e., a “register”—and losing addressability is the price for that; and
    • “negligible” for “inline” is of negligible advantage ;)—both need explanation for what they do, and “inline” lends itself to thinking, “expand this function in-line.”

    1. oops, luckily the text is mutable for me, so I changed the “unmutable”.

      For addressless, I personally really prefer that, since this is the only contract that this concept brings.

      For the others, yeah, I don’t know either. For const I clearly dislike the phrasing “constant variable” that this implies linguistically. This is just a contradiction in terms.

      So please, if you could come up with better coining of some of these terms, I’d be more then happy to put them here.

      1. You could refer to “objects” rather than “variables”, following the Standard; saying “a const object” makes perfect sense.

        1. Hm, not all objects are variables. For me variables are special objects, namely those that have an identifier that refers to them, no? So at points it makes sense just to refer to variables in descriptive text . Something like “the const object to which the identifier x refers…” sounds a bit clumsy.

  4. I know this is more meant for fun, but I think the information should not mislead. I fear that what is mentioned about const here is in fact misleading. const does not mean that the value does not change, it could be mutable. Effectively, const only forbids that machine code which would perform a mutation (value change / bus write cycle if not in register). As the standard clearly mentions in a footnote (in all of them, C89/C90, C99 and C11), const volatile is a valid combination. A use case for a pointer to const volatile could be a memory mapped periphal register which is read-only, and its value could in fact change. Definitions in or pointers to NOR flash or EEPROM memory would correctly be declared as const volatile, too. Only problem is that too many compilers misbehave on const volatile.

    1. I don’t think that “immutable” is misleading. It states that we can not change the value from here, with such a declaration. This is just meant for the difference to “const” with suggest that it never could change. But if you have better idea that would even make things clearer, please go ahead and share it.

  5. Hmmm I get what you want to say and I agree with that of course. It’s just that the word “immutable” in software engineering refers to the fact that it is not changed, by no means. We speak of immutable objects, like the String class in Java, for example. I agree that const is just as misleading, as const by its name suggests it is a constant. I’m just making the point that immutability is a defined term in software engineering that means it really does not change, not that only the compiler couldn’t change it, so it would be just as misleading as const. In Java I like final because it means the first assigned value actually is the last, but we all know that again final != const. I suggest “noassign”, knowing that this might also not sound nice, but maybe it provides inspiration in finding a better term.

    1. Ok, I see what you mean. In the wording of the standard the opposite of const would be a “modifiable lvalue”. So perhaps the term “unmodifiable” would be appropriate. But I am not a native speaker of English, so I don’t know if that is a good idea. Synonyms of that are e.g inalterable or unalterable.

Comments are closed.