Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.std.c
Subject: Re: Interpretation needed Re: function prototypes (LONG)
Message-ID: <1063@cbnewsl.ATT.COM>
Date: 11 Jul 89 15:18:33 GMT
References: <12570014@hpclscu.HP.COM> <12570016@hpclscu.HP.COM>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 36

In article <12570016@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>Thus, the point to be made clear, IMO, is that the "function type" really
>contains an imaginary parameter list, which is identical to the parameter
>list with which it is declared, except that the qualifiers on the parameter
>types are ignored.
>
>E.g., in the function definition
>
>   int foo (const int bar) { /* */ }
>   
>the type of "foo" is
>
>   int () (int)
>
>(my notation for: return type == int, parameter list = "int"). However, the
>type of "bar" is "const int".
>
>Am I off target? Maybe a slight clarification needs to be put into the
>standard or the rationale at some stage.

I think you've got it.  Two types must be compatible before a composite type
from the two can be attempted.  When checking whether two prototypes are
compatible, the "meaningless" type qualifiers are stripped from each parameter,
and each function or array parameter is rewritten as an appropriate pointer
type.  It is this rewritten type that must be used for the composite type
construction.

On the other hand, it doesn't matter whether the "meaningless" qualifiers are
kept in the composite type, since they are always ignored for all purposes,
except within the function definition.

At this point, I doubt that anything will be done to the Rationale or the
pANS, but the interpretations phase of the Committee must answer these sorts
of questions, but it will probably takes months...

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