Message-Id: <200304031956.h33JuWD18264@delorie.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: rrmalloy AT attbi DOT com
To: cygwin AT cygwin DOT com
Subject: Re: Should C/C++ compilers be smart enough to catch this???
Date: Thu, 03 Apr 2003 19:56:20 +0000
X-Authenticated-Sender: cnJtYWxsb3lAYXR0YmkuY29t

Won't -Wreturn suffice?

Rich.
> On Thu, 3 Apr 2003, Fred Ma wrote:
> 
> > Hello,
> >
> > I just spent a great number of hours chasing down a
> > bug that showed itself on g++ on cygwin, but not on
> > g++ on solaris2.5.8.  What did it turn out to be?
> >
> > I had a class member function that returned an
> > object, according to the prototype.  Also according
> > to the function definition.  But, the function body
> > didn't actually contain a return statement.  Like
> > SomeFunc() below:
> >
> >     SomeClass{
> >         //  ...
> >         ReturnType SomeFunc( SomeArgs);
> >         Void AnotherFunc(void);
> >         //  ...
> >     }
> >
> >     ReturnType SomeClass::SomeFunc(SomeArgs){
> >         //    Do stuff,
> >         //    No return statement
> >     }
> >
> >     void SomeClass::AnotherFunc(void){
> >         //    Do stuff...
> >
> >         //    Call SomeFunc():
> >         SomeFunc(SomeArgs);
> >     }
> >
> > This caused corruption that resulted in memory
> > access violations, even though SomeFunc's
> > returned object isn't used AT the point where it
> > is invoked.  The memory violations didn't happen
> > at the point where SomeFunc() was invoked,
> > either, but in a later step in the code.
> >
> > The frustrating thing is that the compiler didn't
> > complain AT all about the discrepancy between
> > the lack of a return statement, even though the
> > function needed one.  I personally find this kind
> > of thing quite common when I reorganize my
> > code e.g. moving functionality in and out of class
> > member functions; that is, the finger details like
> > return types and argument lists change so that
> > it's easy to miss.
> >
> > Shouldn't compilers be smart enough to
> > not create code that corrupts when it is pretty
> > straighforward to realize that (1) there is an
> > obvious discrepancy, for which a warning can
> > easily be issued, or (2) realize that the return
> > type really isnt' being used and compile it in a
> > way that doesn't create memory corruption?
> >
> > Fred
> >
> > P.S.  Since this happens only on cygwin, it
> > might specific to any customizations to g++
> > for cygwin.  All in all, cygwin's gcc is a much
> > better indication of whether my code is buggy,
> > because the solaris executables generally
> > seem to run fine even when there are cringe-
> > inducing bugs, which I only find because they
> > crash on cygwin.
> 
> Use "g++ -Wall".
> 	Igor
> -- 
> 				http://cs.nyu.edu/~pechtcha/
>       |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
> ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
>      |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
>     '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
> 
> Knowledge is an unending adventure at the edge of uncertainty.
>   -- Leto II
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/