Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 '13 at 13:22
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. –  andrew.punnett Apr 10 '14 at 3:08

2 Answers 2

up vote 15 down vote accepted

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.

share|improve this answer
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 '13 at 13:32
@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 '13 at 13:35
@Vorac - The C11 standard is trying propose that _Bool would be a type I used Bool to reflect the decision to add an underscore to a type that might have already been used in the past. Besides bool or Bool the point still stands, while widly accepted that those two types should stand for a Boolean type they might not always. I think this is the best explaination unless the authors of the standard find this question and post their explaination. –  Ramhound May 7 '13 at 13:42
@Vorac: the creators of C had the luxury of designing a language more or less from scratch, with zero user base. Of course bool would meld better with int and void. Some languages have grammars that makes it abundantly clear where a keyword may be used, and where an identifier, never mistaking one for another and thus allowing to add new keywords without breaking existing code. Unfortunately, C is not one of these. –  9000 May 7 '13 at 13:42
@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>. –  Bart van Ingen Schenau May 7 '13 at 13:45

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.

share|improve this answer
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. –  SpaceTrucker May 7 '13 at 14:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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