This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should C/C++ compilers be smart enough to catch this???


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]