Interpretation needed Re: function prototypes (LONG)

[Walter Murray]

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).

[excerpt from pANS deleted]

> The clauses marked (a), (b) and (c) are three distinct combinations of
> function-declarator styles (prototype - prototype, prototype - old-style
> declaration, prototype - old-style definition).

> The debate is whether the parenthesized sentences (especially the one marked
> with "->") apply only to the last combination, or to all three. 

As I read it, the parenthesized sentences 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?:

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

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

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

As I read it, all three examples are legal (strictly conforming),
and in both (a) and (c), "p" is a modifiable lvalue.

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

Why do you say this?  It seems to me that whether "p" may be treated
as modifiable by statements in the function body depends solely on how
"p" is declared in the function definition, and not on how it may
be declared in any other declarations of the function.

In (b) and (c) above, I would say that the composite type of
the function is "int (const int)".
In (a), although I think it's legal, I don't think the pANS defines
the composite type.  Fortunately, it doesn't make any difference,
as far as I can tell, whether the composite type is considered
to be "int (int)" or "int (const int)".

> 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.

I reach the same conclusions.

> Shankar Unni

Walter Murray

In case there's any doubt, these are my personal opinions.
----------