Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!dplace!dsc!kurt
From: kurt@dsc.UUCP (Kurt Luoto  x1006)
Newsgroups: comp.lang.c++
Subject: Re: C++ --> C
Summary: bug in cfront 1.2.1 inline expansions
Keywords: cfront, inline functions
Message-ID: <59@bungo.UUCP>
Date: 21 Apr 89 16:50:36 GMT
References: <173@cs.columbia.edu> <7050005@hpcupt1.HP.COM> <9204@alice.UUCP> <5408@videovax.tv.Tek.com> <9212@alice.UUCP>
Reply-To: kurt@bungo.UUCP (Kurt Luoto)
Organization: DSC - Granger, Santa Clara, Ca.
Lines: 89

In article <9212@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>In article <5408@videovax.tv.Tek.com>, bart@videovax.tv.Tek.com (Bart Massey) writes:
>
>> [ ... stuff about AT&T cfront vs. G++ inline handling ommitted ... ]
>
>I'm not sure what you're trying to say here.  Are you saying that
>cfront inline expansion is often incorrect?  If so, you're wrong.
>Are you saying that cfront handles inline functions by macro-expansion
>on C++ source text?  If so, your're wrong there too.
>
> [ ... more defense of AT&T cfront inline handling ommitted ... ]
>
>      Cfront does everything a GNU C++ that produces C would.  It does
>the same kind of complete syntax and semantic analysis that any compiler
>does, resulting in an internal data structure that it traverses to
>produce C.  If it didn't do a full analysis, it would routinely
>translate erroneous C++ programs into erroneous C programs --
>but it doesn't.
>
>  [  ... ]
>
>				--Andrew Koenig
>				  ark@europa.att.com

This is not exactly a rebuttal,
but as a recent C++ (AT&T cfront 1.2.1) user, it did bring to mind
a bug that I discovered regarding its handling of inline functions
(forgive me if this has already been noted before).

The following C++ code:

   -------------------------------------------------------------
   // Sample program to show bugs in cfront inline expansion
   // in cfront 1.2.1  2/16/87.

   class foo {
      int  x ,y ;
      void  setXY( int k ) ;
   public:
      foo() { x = y = 0 ; }
      void  bar( ) ;
      };

   inline void  foo::setXY( int k ) {
      x = k ;
      y = k ;
      }

   void  foo::bar( ) {
      setXY( x + 1 );
      }
   -------------------------------------------------------------

produces the following C code as output
(edited slightly to make more readable to humans):

   -------------------------------------------------------------
   /* <<cfront 1.2.1 2/16/87>> */
   struct foo {	/* sizeof foo == 8 */
      int _foo_x ;
      int _foo_y ;
      };

   char _foo_setXY ();
   char _foo_bar ();

   char _foo_bar (_au0_this )
      struct foo *_au0_this ;
      { 
      (  (_au0_this -> _foo_x = (_au0_this -> _foo_x + 1 )),
	 (_au0_this -> _foo_y = (_au0_this -> _foo_x + 1 ))  ) ;
      } ;

   /* the end */
   -------------------------------------------------------------

The semantics of a procedure call have not been accurately reproduced
with this inline expansion.
It is clear from the C++ code that the routine foo::setXY() should set
both member fields x and y to the same value.
However, as expanded inline in the body of foo::bar(), field y will wind up
with a value one greater than that of field x.

By the way, is there yet a published bug list for cfront 1.2.1 ?
Is there a more recent version that fixes this and other bugs?

-------
Kurt Luoto   (neophyte news-poster)
(If I knew my e-mail address, I'd give it.)