Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!polyslo!decwrl!hplabs!hp-ses!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.std.c
Subject: Interpretation needed Re: function prototypes (LONG)
Message-ID: <12570014@hpclscu.HP.COM>
Date: 5 Jul 89 17:15:51 GMT
Organization: Hewlett-Packard Calif. Language Lab
Lines: 77

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

     For two function types to be compatible, both shall specify compatible
     return types. Moreover, the parameter type lists, if both are present,
(a)  shall agree in the number of parameters and in the use of the ellipsis
     terminator; corresponding parameters shall have compatible types.

									 If
     one type has a parameter type list and the other type is specified by
     a function declarator that is not part of a function definition and that
     contains an empty identifier list, the parameter list shall not have an
(b)  ellipsis terminator and the type of each parameter shall be compatible
     with the type that results from the application of the default argument
     promotions.

		 If one type has a parameter type list and the other type is
     specified by a function definition that contains a (possibly empty)
     identifier list, both shall agree in the number of parameters and the
(c)  type of each prototype parameter shall be compatible with the type that
     results from the application of the default argument promotions to the
     type of the corresponding identifier.

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


(Phew!)

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. 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? */ }

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

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?

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.

Could the gurus please impart their wisdom to us on this earth-shaking topic?
It will be much appreciated. (p.s. the non-gurus are welcome with their
opinions, too, so don't be shy :-)).
--------
Shankar Unni
Hewlett-Packard California Language Lab.      Internet: shankar@hpda.hp.com
Phone: (408) 447-5797                             UUCP: ...!hplabs!hpda!shankar