[comp.lang.c++] Bug in 2.0 with Pass by Reference?

stan@csam.lbl.gov (See-Mong Tan) (01/07/90)

I seem to have stumbled upon a bug with cfront 2.0.
It has to do with passing a variable by reference.  It failed
in this code here:

There are two functions, the first is:

> int FSI::pathOpen( char *, StoredObject * &, Class *);

Note that it expects the second argument to be a variable that's
passed by reference.

The next function calls the first:

> int FSI::keys(char *dirname, char *buf, int size, int &count)
> {
> 	ObjectDictionary * od = 0;
>       // call pathOpen, pass variable od by reference
> 	int status = pathOpen( dirname, od, ObjectDictionaryClass );
> 	....
> }

The generated code for the second function however, looks like:

> int keys__ [... declarations ..]
> {
> 
> struct ObjectDictionary *__1od;
> int __1status;
> 
> {
> struct StoredObject *__0__I36;             // A temporary variable?
> 
> __1status = pathOpen__3FSIFPcRP12StoredObjectP5Class ( __0this, __0dirname, (struct StoredObject **) ( (__0__I36 = (struct StoredObject *) __1od ), (& __0__I36 )) , ObjectDictionaryClass);
> 
> ...
> }
> 
> }

Notice that the call to pathOpen does not correctly pass by reference
the second argument... why does this happen?

It happened on a Cray first, with the cfront I ported, 
so I thought I broke something, but then cfront 2.0 for the
Suns here gave the same output.  Is there a fix for this?

stan

ark@alice.UUCP (Andrew Koenig) (01/08/90)

In article <4577@helios.ee.lbl.gov>, stan@csam.lbl.gov (See-Mong Tan) writes:

> int FSI::pathOpen( char *, StoredObject * &, Class *);

> 	ObjectDictionary * od = 0;
> 	int status = pathOpen( dirname, od, ObjectDictionaryClass );

So od is an ObjectDictionary* and FSI::pathOpen takes a second
argument that is a reference to a StoredObject*.  The two pointer
types StoredObject* and ObjectDictionary* are different types.
It is not possible to bind a StoredObject*& to an ObjectDictionary*
object.  This is true even if ObjectDictionary is derived from
StoredObject -- just because you can bind a StoredObject& to an
ObjectDictionary, that doesn't mean you can bind a StoredObject*&
to an ObjectDictionary*.

One way to see this more clearly is to realize that converting from
ObjectDictionary* to StoredObject* might involve a change in internal
representation in the presence of multiple inheritance.
-- 
				--Andrew Koenig
				  ark@europa.att.com

sechrist@hp-ses.SDE.HP.COM (Nancy Sechrist) (01/16/90)

Andrew,
     I understand your explanation that it is not correct to attempt
to bind a StoredObject*& to a ObjectDictionary*. However, the symptom
is that cfront lets this pass through without even a warning. The
result is code that mis-behaves. Shouldn't cfront emit an error?

Nancy Sechrist
Hewlett Packard
sechrist@hp-ses.hp.com

ark@alice.UUCP (Andrew Koenig) (01/16/90)

In article <830007@hp-ses.SDE.HP.COM>, sechrist@hp-ses.SDE.HP.COM (Nancy Sechrist) writes:

>      I understand your explanation that it is not correct to attempt
> to bind a StoredObject*& to a ObjectDictionary*. However, the symptom
> is that cfront lets this pass through without even a warning. The
> result is code that mis-behaves. Shouldn't cfront emit an error?

Cfront 2.1 will be much more agressive than 2.0 about giving
warnings about this sort of thing.
-- 
				--Andrew Koenig
				  ark@europa.att.com