Interpretation needed Re: function prototypes (LONG)

[david.f.prosser]

In article <12570014 at hpclscu.HP.COM> shankar at hpclscu.HP.COM (Shankar Unni) writes:
>A question has come up with regard to the interpretation of a parenthesized
>sentence in Sec 3.5.4.3 (page 69, lines 24, 25 in the Dec 88 draft).
>
>I'll quote here in full the paragraph in question (I've put in some blank
>lines between conditions, just to make it a little easier to read - in the
>standard document, all this is one giant paragraph):

There's a good reason why it's all one paragraph--so that the applicability
of the parenthetical sentences would be clear.

	[most of the quoted text deleted]

>					   (For each parameter declared with
>     a function or array type, its type for these comparisons is the one that
>     results from conversion to a pointer type, as in Sec 3.7.1. For each
>(->) parameter declared with a qualified type, its type for these comparisons
>(->) is the unqualified version of its declared type.)
>
>The debate is whether the parenthesized sentences (especially the one marked
>with "->") apply only to the last combination, or to all three.

They apply to the entire paragraph.

>Specifically,
>are all the following correct combinations of declarations? If so, what
>are the composite types of these function types?:

There is a misunderstanding here.  The parenthetical sentences are not
differences in type that participate in producing a (possibly different)
composite type.  Many people also seem to believe that type qualifiers
have this sort of connection with composite types, for whatever reason.
These sentences state that these "rewrites" of the parameter types are
part of the type comparison: types that are the same after the rewrite
are the same.

>
>(a)  int func1 (const int);
>     int func1 (int p)       { /* can "p" be modified here? */ }

Yes.  The type of the parameter is "int".

>
>(b)  int func2 ();
>     int func2 (const int);

These are compatible types.

>
>(c)  int func3 (const int);
>     int func3 (p) int p;    { /* can "p" be modified here? */ }

Yes.  The parameter has type "int".

>
>In both (a) and (c), this is a crucial question. The composite type
>determines whether "p" is a const or not (in the body).

No.  The rules for composite types have nothing to do with qualified
or unqualified versions of types.  The composite type for all of the
above examples is the same: function returning int with one int parameter.
Only those differences listed in section 3.1.2.6 (array with unknown vs.
known size, function without parameter information vs. with parameter
information) come into action in the creation of a composite type.

>
>Another question is: if any of these is deemed to be wrong (let's say
>that the types in (a) are not compatible): Am I violating a constraint
>if I allow assignment to "p"? What if the declaration had  no const and
>the definition had one?

All the above examples are compatible, but it is the actual type of the
function definition that determines the allowed behavior in the function:

	int f(const int);
	int f(int a){return ++a;}	/* valid */

	int g(int);
	int g(const int a){return ++a;}	/* invalid, but only due to the ++ */

>
>My personal opinion (based on a "gut feeling") is that qualifiers should
>be stripped from definitions *for the purposes of comparisons only*. I.e.
>in case (a), the combination should be OK, and "p" should be modifiable.
>If it was the other way round (declaration without "const", definition with
>"const"), then "p" should not be modifiable. It shouldn't matter to the
>caller whether the parameter is a const or not - it will never change
>the semantics of the actual call.

This is what the pANS describes.  It is unfortunate that the draft doesn't
seem to make it clear, and you have to rely on "gut feelings".

Dave Prosser	...not an official X3J11 answer...