Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!rex!samsung!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpcc01!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.lang.c++
Subject: Re: ansi c output from cfront(s)
Message-ID: <58170030@hpclscu.HP.COM>
Date: 21 Aug 90 00:55:11 GMT
References: <9008181728.3322@nowhere.uucp>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 30

>    class foo {
>    public:
>       foo();
>       ~foo();
>    };
> 
> what is emitted for the destructor is a proto of the form
>    void __dt__3fooFv(struct foo *__0this, int );
> the only "ansi c" compiler I have available to me (Microsoft C 6.0) chokes on
> this. Which has the bug, the cfront(s) or MSC?

Actually, both.

MSC is the more glaring violator, because the ANSI C standard explicitly
allows you to leave out parameter names on any of the parameters (i.e.
parameter names for external function declarations are totally optional,
and there is no requirement for them to be all present or all absent).

Cfront is also a contributor to this fiasco: it should not be putting out
parameter names for external declarations. In fact, one of the more serious
bugs in cfront 2.0 is that sometimes these name nodes get reclaimed and
re-used, and then when it finally gets around to dropping the prototype,
one gets interesting declarations like:

   void __dt__3fooFv(struct foo *__03.14159, int );

-----
Shankar Unni                                   E-Mail: 
Hewlett-Packard California Language Lab.     Internet: shankar@hpda.hp.com
Phone : (408) 447-5797                           UUCP: ...!hplabs!hpda!shankar