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

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

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/