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
X-Authentication-Warning:	slinky.cs.nyu.edu: pechtcha owned process doing -bs
Date:	Thu, 3 Apr 2003 14:40:59 -0500 (EST)
From:	Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To:	cygwin AT cygwin DOT com
To:	Fred Ma <fma AT doe DOT carleton DOT ca>
cc:	cygwin AT cygwin DOT com
Subject:	Re: Should C/C++ compilers be smart enough to catch this???
In-Reply-To:	<3E8C8C4F.ABC60B0F@doe.carleton.ca>
Message-ID:	<Pine.GSO.4.44.0304031440070.21921-100000@slinky.cs.nyu.edu>
Importance:	Normal
MIME-Version:	1.0

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/

- Raw text -