Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3E8C8C4F.ABC60B0F@doe.carleton.ca>
Date: Thu, 03 Apr 2003 14:32:31 -0500
From: Fred Ma <fma AT doe DOT carleton DOT ca>
MIME-Version: 1.0
Newsgroups: comp.unix.programmer,gnu.gcc.help
To: cygwin AT cygwin DOT com
Subject: Should C/C++ compilers be smart enough to catch this???
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.


--
Fred Ma, fma AT doe DOT carleton DOT ca
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6


--
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/