🚀 go-pugleaf

In article <44fkc3$hj3@news0.rain.rg.net>, Paul Long <plong@perf.com> writes: 
|> What is the type of a parameter in a composite type that is constructed
|> from two function types whose corresponding parameters have incompatible
|> types? (Whew!) For example, what is the type of the composite type's

The parameters can only be incompatible as to their type qualifiers
(otherwise you have syntax violation). As two functions whose parameters
differ in their type qualifiers are completely compatible, it does not make
sense to ask what the type qualifiers of the parameters of a function type
are. As you are asking about the properties of the composite _type_, I do not
think your question has a meaningful answer.

However, the wording of the standard was, I believe, in defect. 6.1.2.6
clearly called for a composite type from incompatible types as your example
below shows. However the TC1 that you quote removes this defect, and the
composite type is clearly `void(int)'.

By the way, does this mean that that after

int f(const int);
int g(const int);
int g(const int);

f has type int(const int) because types do not need to be composed: there is
only one declaration, but g has type int(int)? Maybe, but it does not have
any observable effects yet. However such curiosities bother me because
some simple change in the standard can someday make this clearly
unintended difference observable; and that I cannot think of what that
dangerous change is, should be no reason to not fix this. This probably ought
to be corrected by stating that the parameter qualifiers are never a part of
the function type. 

|> parameter that is constructed from the following function declarations?
|> 
|>     void foo(volatile);
|>     void foo(const a) {
|>         a = 3;
|>     }
|> 
|> Technical Corrigendum 1 says that "In the determination of type
|> compatibility and of a composite type, ... each parameter declared with
|> qualified type is taken as having the unqualified version of its declared
|> type." So does that means that

Note that the sentence does not apply to the determination of the type of
parameter `a': it applies to determination of the compatibility and
the composite type of the function. In absence of any specific statement to
the contrary, `a' continues to be `const int' (even though the composite
function type is void(int).)

|>     1. the types of my two foo declarations are compatible,

Yes.

|>     2. the composite type of the parameter is int,

Yes.

|>     3. a is a modifiable lvalue, and

No. The TC1 statement clearly shows (in its use of `In the determination of
type compatibility and of composite type' as a qualifier) that the type of a
parameter and the `type of the parameter in the prototype part of the
function type' need not be the same.

|>     4. this is a conforming program?

No.

(Add IMHO to all above).

Cheers
Tanmoy
-- 
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]