CODEWITHSUNDEEP
clanguage-lawyerdiagnosticsstandards-compliancec17
pmor
pmor

Reputation: 6296

What is the rationale for "semantics violation does not require diagnostics"?

Follow-up question for: If "shall / shall not" requirement is violated, then does it matter in which section (e.g. Semantics, Constraints) such requirement is located?.

ISO/IEC 9899:202x (E) working draft— December 11, 2020 N2596, 5.1.1.3 Diagnostics, 1:

A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Diagnostic messages need not be produced in other circumstances.

Consequence: semantics violation does not require diagnostics.

Question: what is the (possible) rationale for "semantics violation does not require diagnostics"?

Upvotes: 1

Views: 152

Answers (4)

supercat
supercat

Reputation: 81267

The question of whether an implementation provides any useful diagnostics in any particular situation is a Quality of Implementation issue outside the Standard's jurisdiction. If an implementation were to unconditionally output "Warning: this program does not output any useful diagnostics" or even "Warning: water is wet", such output would fully satisfy all of the Standard's requirements with regard to diagnostics even if the implementation didn't output any other diagnostics.

Further, the authors of the Standard characterized as "Undefined Behavior" many actions which they expected would be processed in a meaningful and useful fashion by many if not most implementations. According to the published Rationale document, Undefined Behavior among other things "identifies areas of conforming language extension", since implementations are allowed to specify how they will behave in cases that are not defined by the Standard.

Having implementations issue warnings about constructs which were non-portable, but which they would process in a useful fashion would have been annoying.

Prior to the Standard, some implementations would usefully accept constructs like:

struct foo {
  int *p;
  char pad [4-sizeof (int*)];
  int q,r;
};

for all sizes of pointer up to four bytes (8-byte pointers weren't a thing back then), rather than squawking if pointers were exactly four bytes, but some people on the Committee were opposed to the idea of accepting declarations for zero-sized arrays. Thus, a compromise was reached where compilers would squawk about such things, programmers would ignore the useless warnings, and the useful constructs would remain usable on implementations that supported them.

While there was a vague attempt to distinguish between constructs that should produce warnings that programmers could ignore, versus constructs that might be used so much that warnings would be annoying, the fact that issuance of useful diagnostics was a Quality of Implementation issue outside the Standard's jurisdiction meant there was no real need to worry too much about such distinctions.

Upvotes: 2

Basile Starynkevitch
Basile Starynkevitch

Reputation: 1

A possible rationale is given by Rice's theorem : non-trivial semantic properties of programs are undecidable

For example, division by zero is a semantics violation; and you cannot decide, by static analysis alone of the C source code, that it won't happen...

A standard cannot require total detection of such undefined behavior, even if of course some tools (e.g. Frama-C) are sometimes capable of detecting them.

See also the halting problem. You should not expect a C compiler to solve it!

Upvotes: 4

alinsoar
alinsoar

Reputation: 15803

This happens because the grammar of the C language is context-sensitive and for all the languages that are defined with context-free or more complex grammars on the Chomsky hierarchy one must do a tradeoff between the semantics of the language and its power.

C designers chose to allow much power for the language and this is why the problem of undecidability is omnipresent in C.

There are languages like Coq that try to cut out the undecidable situations and they restrict the semantics of the recursive functions (they allow only sigma(primitive) recursivity).

Upvotes: 2

Lundin
Lundin

Reputation: 214780

The C99 rationale v5.10 gives this explanation:

5.1.1.3 Diagnostics

By mandating some form of diagnostic message for any program containing a syntax error or constraint violation, the Standard performs two important services. First, it gives teeth to the concept of erroneous program, since a conforming implementation must distinguish such a program from a valid one. Second, it severely constrains the nature of extensions permissible to a conforming implementation.

The Standard says nothing about the nature of the diagnostic message, which could simply be “syntax error”, with no hint of where the error occurs. (An implementation must, of course, describe what translator output constitutes a diagnostic message, so that the user can recognize it as such.) The C89 Committee ultimately decided that any diagnostic activity beyond this level is an issue of quality of implementation, and that market forces would encourage more useful diagnostics. Nevertheless, the C89 Committee felt that at least some significant class of errors must be diagnosed, and the class specified should be recognizable by all translators.

Upvotes: 2

Related Questions