0

In the 7.1.3 of the C11 standard are listed some rules about which are the reserved identifiers.

At the end is said:

No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

However, if I try with GCC to break one of those rules, for example I write something like int __A; the compiler tells me nothing. Now maybe I did not understand well, but then which of those rules define the fact that you can have an undefined behavior?

xdevel2000
  • 20,780
  • 41
  • 129
  • 196
  • 2
    possible duplicate of [Undefined, unspecified and implementation-defined behavior](http://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior) – Deduplicator Dec 01 '14 at 16:10
  • @Deduplicator, my question is not what's an UB but if all the rules can generates an UB! – xdevel2000 Dec 01 '14 at 16:19
  • @xdevel2000, not all, just those which say so. This one says so. The standard should have every part of the language defined (declaring something UB is fine from the point of the standard: it explicitly defines a particular case to be an UB). The point of UB as I see is that it clearly defines in which cases a compiler may do "arbitrary stuff": if on a particular behavior there is no such declaration in the standard, the behavior should be at least deductible. – Jubatian Dec 01 '14 at 16:38
  • @Jubatian: No, the standard only explicitly calls out UB in some cases. Where it does not define anything, it is undefined by omission. – Deduplicator Dec 01 '14 at 20:03
  • @Deduplicator: well, never tried to get into the depths of a C compiler to experience this, just out of curiosity: could you point me to one or two of such omissions which are particularly interesting / critical? I interpreted these somewhat like "Hey, you, compiler! Here you can do whatever you want, but everywhere else it's no-no for messing around!". – Jubatian Dec 01 '14 at 22:39
  • Just look at chapter 4, *conformance*: `If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtimeconstraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.` – Deduplicator Dec 01 '14 at 22:41
  • @Deduplicator: Uh. This is scary (`...omission of any explicit definition of behavior.`). I just wouldn't except such to be read in a specification, much less in one which is a standard (in safety crit. such is completely unacceptable even by the standards we have to conform with). Well, also proves I never read either C standard from start to end (or that I fell asleep in the process). – Jubatian Dec 02 '14 at 10:17

2 Answers2

5

A possible outcome of undefined behavior is that you get no warnings, no errors, and everything works fine.

Another outcome is that you upgrade your compiler by a point-release and previously working code starts breaking.

Bill Lynch
  • 80,138
  • 16
  • 128
  • 173
  • Yes, I know; but maybe my question is not clear. I'd like to know if UB is only if I, i.e, redefine an identifier already declared into a library header or also if I write an identifier like __a that is not declared inside no header. I hope this is clearer. Thanks. – xdevel2000 Dec 02 '14 at 09:24
  • It's undefined behavior in either case. That being said, I can't imagine a compiler faulting on that code if it doesn't use the identifier. – Bill Lynch Dec 02 '14 at 13:57
0

The compiler might warn you about undefined behaviour but it doesn't have to. And in many cases it doesn't. For GCC you should at least use the options -Wall -Wextra but it wont help in this case.

A static analysis tool such as splint, PC-Lint, QA-C, etc. will give you much more warnings about undefined behaviour.

Lars Ljung
  • 375
  • 2
  • 6