Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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
up vote 16 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 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
@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 '13 at 13:51
@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 '14 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.

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.