[comp.std.c] Optional vs. required diagnostics

karl@haddock.ima.isc.com (Karl Heuer) (07/25/90)

Must the following code fragments generate a diagnostic?
	/* [0] */ double *p;   int x;   p = &x;
	/* [1] */ void f(double *p);   int x;   f(&x);

[0] is illegal because of 3.3.4 ("Conversions that involve pointers (other
than ...) shall be specified by means of an explicit cast"), but since it
appears under Semantics rather than Constraints, it seems to be merely a
case of undefined behavior, and hence the compiler may choose to be silent.

[1] is similar, but the place where 3.3.2.2 requires assignment-compatibility
for prototype arguments *is* under the Constraints section.  Does this cause
the implicit reference to 3.3.4 to be covered by the 3.3.2.2 Constraints
for this particular case, and hence require a diagnostic?  Or can an
implementation choose to accept [0] as a Conforming Extension and then claim
that [1] does not violate 3.3.2.2, since, *in this implementation*, the
actual and formal parameters *are* assignment-compatible?

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint

walter@hpcllca.HP.COM (Walter Murray) (07/25/90)

Karl Heuer asks:

> Must the following code fragments generate a diagnostic?
> 	/* [0] */ double *p;   int x;   p = &x;
> 	/* [1] */ void f(double *p);   int x;   f(&x);

I believe both fragments require diagnostics.

Maybe I'm missing something here, but it seems to me the key
section of the standard is 3.3.16.1, Simple Assignment.  It
contains a single constraint, stating that in a simple assignment
one of five conditions must hold.  Your fragment [0] contains
a simple assignment for which none of those conditions hold, so
it violates the constraint and must be diagnosed by a conforming
compiler.  Anyone who claims that a diagnostic is not required
should say which of the five conditions does hold.

Likewise, fragment [1] violates a constraint in 3.3.2.2, because
the assignment would be illegal.  It's 3.3.16.1 that tells us
the assignment is illegal.

As I see it, the clause in 3.3.4 beginning, "Conversions that involve
pointers ..." could be deleted without changing the standard.  It is
only serving to introduce the following four paragraphs.

Walter Murray
----------