Not true; a fully conforming implementation of C99 can provide it's own
definition of the behavior of a program whenever it contains specific
features that render it's behavior undefined by the C99 standard.
Extensions implemented by making use of that fact do not interfere with
conformance. Example: extensions that occur only when your code uses a
identifier that is, in it's context, reserved to the implementation,
such as __aligned. A #pragma statement (or _Pragma() expression) is
another mechanism that a fully conforming implementation of C can use to
turn an extension on or off.
These same mechanisms could also be used to trigger extensions which
give the user control over behavior that is unspecified by the C
standard, without rendering the implementation non-conforming.
Somewhat more obtrusive, but still fully conforming, would be an
extension that gives meaning to code that constitutes a syntax error or
a constraint violation. A fully conforming implementation of C can
accept such code, so long as it generates a corresponding diagnostic,
such as "Congratulations on using our forma-link extension! We hope you
enjoy using it.".
ya but if I write code like
return main(void) { int 0; }
That's clearly totally bogus C99 syntax but his compiler might [I know
it doesn't I'm just making up an example] say "hey that's cool, I got
this!"
The only thing that the C standard requires of a fully conforming
implementation of C when the source code contains a syntax error is a
diagnostic message. Whatever else the implementation chooses to do after
issuing the diagnostic message has no impact on whether or not it
conforms to the C standard.
There only needs to be one such diagnostic, no matter how many different
syntax errors or constraint violations the code contains. The message
doesn't have to say where the syntax error occurred. The message doesn't
have to say anything useful at all. It doesn't even have to be in any
known language. About the only restrictions imposed by the standard on
the contents of a diagnostic is that diagnostics must be identifiable as
such, and the way they can be so identified must be explained in the
documentation for that implementation.
If the C99 specifies "implementation defined" syntax e.g. #pragma then
it's not a C99 syntax violation it's just not portable.
True, any code which relies upon the use of extensions is not portable
to any compiler which fails to support those extensions. That's not
exactly big news. But accepting non-portable code is the norm, not the
exception, with C compilers. It does not, in itself, prevent them from
being fully conforming compilers - not even when working in the mode
where they accept such code.
However, if he used #prada instead that's not defined [as
implementation or otherwise] and should result in an error.
A line starting with "#prada" is one example of what the C standard
calls a non-directive (6.10p1). As pointed out in footnote 150, despite
the name, non-directives count as preprocessing directives, as far as
parsing C code is concerned. Therefore, so long as a non-directive does
not begin with one of the standard preprocessing directive names
(6.10p3), it is not a syntax error for a C program to contain one.
There's one, and only one, feature that a program can possess that
prohibits a conforming implementation of C from accepting the program: a
#error directive that survives conditional compilation (4p4). A #prada
non-directive doesn't qualify.
