I am currently reading a draft of the C11 specification. The new introduced keywords: _Bool, _Alignof, _Atomic all feel like custom extensions, instead of standard reserved keywords like struct, union, int.

I realize that the standard basically consists of standardized extensions ... but still, this is awful! Maybe we will soon end up with __Long_Long_Reallylong_Integer_MSVC_2020_t creeping in the standard!

Is the backward compatibility of nonstandard code the only reason of the new style of the keywords?

  • 2
    Nah, I wouldn't worry about really long types like that. The number of letter and number combinations of _, a-z, A-Z, and 0-9 means they'd probably just be short and hard to remember instead.
    – Neil
    May 7, 2013 at 13:22
  • 2
    A nicer looking synonym for each keyword is often defined in the relevant standard library header file. For example, any C11 implementation's <stdbool.h> header file must include a preprocessor macro such as #define bool _Bool. This is a neat solution as it retains backwards compatibility, but allows any new code, which includes the new header file, to use the more attractive syntax.
    – andypea
    Apr 10, 2014 at 3:08

2 Answers 2


I imagine that backwards compatibility with perfectly standard code is a more important reason.

If you add a keyword that might have been used as a legitimate identifier in previous code, you create a ton of pain, of possible subtle errors, especially in C, a language with somehow complicated parsing rules.

If these identifiers were used as a public interface somewhere, you add pain to all users of such unfortunate libraries, who might not use C at all, but call the library from Ruby, or Python, etc.

That's why new keywords are bound to look less like nice words and more like bolt-on hacks that people have smaller chances of already using for another purpose.

  • It should be pointed out that the question was with regards to C not C++ not that it matters. Your answer covers the reason that a new supoprted type would be named something to avoid using causing a conflict with a custom type Bool in legacy code which was widly accepted to be a Boolean but never actually part of the C standard so the assumption is not safe to make.
    – Ramhound
    May 7, 2013 at 13:32
  • 1
    @Ramhound, IMHO bool would be more in the spirit of C. Also, I am not completely convinced by this answer, as ugly words might also have been used by non-standard code. And changing the style of the words makes standard words harder to recognize at a glance.
    – Vorac
    May 7, 2013 at 13:35
  • 6
    @Vorac: The problem is that if bool was added unconditionally to the language, then all projects that have their own (perfectly legitimate) version of bool would stop compiling. That would seriously harm the acceptance of the language revision. This is the reason that all new identifiers are being taken from the reserved set (thus beginning with _[capital]). As there was also a large demand for bool itself, this has been added as typedef _Bool bool in <stdbool.h>. May 7, 2013 at 13:45
  • 1
    @BartvanIngenSchenau - Which allows people to replace their own typedef of a Boolean value to one contained within stdbool.h or update their own typedef to the new type to support their legacy code.
    – Ramhound
    May 7, 2013 at 13:51
  • 1
    @Ramhound - people with variables that conflicted with new C11 keywords could also "So don't use it?". There is a compile flag std=xxx to prevent any conflicts with new language standards.
    – Scooter
    Oct 25, 2014 at 2:46

Names beginning with an underscore and a capital letter (and anything with double underscore) were reserved for compiler/standard library implementation in previous standards.

From Reserved Identifiers of C89 and C99:

Also reserved for the implementor are all external identifiers beginning with an underscore, and all other identifiers beginning with an underscore followed by a capital letter or an underscore.

So in theory, those new keywords should not be in use in any code writen before and that leads to better backward compatibility than any simple name, which is likely the only reason.

  • 4
    You should cite and possibly link to or name the appropriate standards section, so others can verify your statement quickly. This will improve your answer. May 7, 2013 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.