Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!flanagan
From: flanagan@odin.cs.cornell.edu (Doug Flanagan)
Newsgroups: comp.lang.c++
Subject: bugs/help request
Message-ID: <23331@cornell.UUCP>
Date: 9 Dec 88 20:45:01 GMT
Sender: nobody@cornell.UUCP
Reply-To: flanagan@cs.cornell.edu (Doug Flanagan)
Distribution: comp
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 102


One of our C++ users reports the following problems. We are running
C++ 1.2 from AT&T on Sun 3/50's. I personally don't use C++ so it could 
well be that this user's code is wrong. If it isn't, I'm sure he would
appreciate knowing what he is doing wrong. If it is correct, I would like
to know what some of the other C++ compilers for Suns do with these
examples. If you are running C++ on a Sun, could you please try these
and tell me your results (and what C++ compiler you are using)?
Thank you. E-mail replies to me:

-Doug Flanagan (flanagan@lnssun1.tn.cornell.edu)
 Cornell Lab. of Nuclear Studies

*************************************************************************
Here is a report of two bugs in our C++ compiler (cfront 1.2.1 2/16/87):
Bug 1:
Description:  One can not declare automatic variables of type pointer
    to vector (without using typedefs).

Example:
-------------------------------------------------------------------------------
int (*pv)[10];			// works

void f()
{
    static int (*pv2)[10];	//works
    int (*pv1)[10];		//doesn't work
}
-------------------------------------------------------------------------------
when compiled using CC -c, produces the following terminal output.
% CC -c pv1.c
CC  pv1.c:
"pv1.c", line 7: error:  pv1 is undefined
"pv1.c", line 7: warning: result of [] expression not used
1 error

Typedefs provide a partial way around this;  however, they are not perfect:


Bug 2:
Description:   delete generates an internal compiler error when one attempts
to delete space pointed to by a pointer to vector of structures:

Example:
-------------------------------------------------------------------------------
struct x_s {
    int a;
    int b;
};

void f(int n)
{
    typedef x_s Vec10x[10];
    Vec10x *px;	
    px = new Vec10x[n];	// works; produces "illegal pointer combination"
    delete px;
}			// line 12
-------------------------------------------------------------------------------
when compiled using CC -c produces the following terminal output:
% CC -c pv2.c
CC  pv2.c:
"pv2.c", line 12: internal <<cfront 1.2.1 2/16/87>> error:  expression::simpl: delete vector
1 error

If one replaces x_s with int in the typedef, the code compiles.
(Finally, if one comments out the "delete px" line, one gets:
% CC -c pv2.c
CC  pv2.c:
cc  -c  pv2..c
"pv2.c", line 10: warning: illegal pointer combination
which should not happen, but the resulting code looks correct.)

It is rare that one actually want to use a pointer to vector, and one can 
usually use pointer to pointer instead, but "rare" does not mean "never"!


Bug 3:
Example:
----------------------------------------------------------------------
/* File t.c */

struct A { int i; };
struct B { A& a; B(A&);}; // B::a is a reference to variable of type A
B::B(A& b) : a(b) {} //line 5:  initialization of B::a to b causes trouble


This is what happens when you try to compile this file on a SUN 3/50:

% CC -c t.c
CC  t.c:
"t.c", line 5: internal <<cfront 1.2.1 2/16/87>> error: bus error (or something nasty like that)
1 error
%

Compiling with flag -Fc one finds that cfront gets into the definition
of B::B(A&) but dies at the point where it wants to initialize B::a; the 
last fragment of a line it writes is 
                            _au0_this -> _B_a = 
after which it dies. On a MacII (rather than a SUN 3/50) cfront 
often gets past this point, and does the right thing. However it usually
has trashed something else in memory, often leading to rather interesting
consequences 5-10 minutes later.