Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.c++
Subject: Re: A real cfront bug
Keywords: cfront ANSI C declaration disagrees with definition
Message-ID: <10258@socslgw.csl.sony.JUNET>
Date: 16 May 89 07:44:39 GMT
References: <9671@watcgl.waterloo.edu>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Distribution: comp
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 45

In article <9671@watcgl.waterloo.edu> ahvermen@watcgl.waterloo.edu (Al Vermeulen) writes:

>I think that the following piece of code honestly does demonstrate the
>cfront bug that's bothering me:

1 >struct A {
2 >    A::A( A& )   {}
3 >};
4 >
5 >void func(A);
6 >
7 >void func( A )
8 >{
9 >}

>cfront produces the following (incorrect) ANSI C code:

Cfront allows the defininition on line 7?  A type with no formal
parameter named?

># 5
>char func (struct A );

># 7
>extern char func (_au0__A2 )struct A *_au0__A2 ;
>{ }
>;

>Notice that the declaration of func (line # 5) specifies that func
>takes an instance of struct A, the definition of func (line #7) says
>func takes a pointer to a struct A.  I believe that the definition
>(line #7) is correct, since the code compiles fine on another machine
>we have that does not use ANSI C.

What code is emitted on your other machine?  Or is it a pure compiler?

What is your real line 7?  If your code actually defines
void func (A* x)   or   void func (A& x)  , then it really is different
from line 5.

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-implementing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?