Path: utzoo!attcan!uunet!lll-winken!xanth!nic.MR.NET!indri!csd4.milw.wisc.edu!uxc!iuvax!watmath!watcgl!ahvermen
From: ahvermen@watcgl.waterloo.edu (Al Vermeulen)
Newsgroups: comp.lang.c++
Subject: A real cfront bug
Keywords: cfront ANSI C declaration disagrees with definition
Message-ID: <9671@watcgl.waterloo.edu>
Date: 12 May 89 15:23:15 GMT
Distribution: comp
Organization: U of Waterloo, Ontario
Lines: 56

In my last posting I posted some code that did not demonstrate the 
particular bug I'm worried about.  My apologies to the net.  I think
that the following piece of code honestly does demonstrate the cfront
bug that's bothering me:

code:

struct A {
    A::A( A& )   {}
};

void func(A);

void func( A )
{
}


cfront produces the following (incorrect) ANSI C code:

# 1 "weird.c"

/* <<cfront 1.2.1 2/16/87>> */
/* < weird.c */

# 1 "weird.c"
char *_new(); char _delete(); char *_vec_new(); char _vec_delete();

# 1
struct A {
char _dummy; };

# 5
char func (struct A );

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

/* the end */


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.  I can't change cfront to emit K&R
(rather than ANSI) C because I don't have source.

My current work around is to pass references to A, and make local variable
copies in func().  Is this bug fixed in version 2.0?
-- 

Al Vermeulen (al@watsup, ahvermen@watcgl)
al@watsup.waterloo.edu