🚀 go-pugleaf

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.
> 
> --
> Fred Ma, fma@doe.carleton.ca
> Carleton University, Dept. of Electronics
> 1125 Colonel By Drive, Ottawa, Ontario
> Canada, K1S 5B6

Did you run the compiler with -Wall?

Speaking only for myself,

Joe Durusau

On 3 Apr 2003 19:32:34 GMT, Fred Ma <fma@doe.carleton.ca> wrote:


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

-Wall is your friend.

-- 
Alex Pavloff - remove BLAH to email
Software Engineer, Eason Technology 

Fred Ma <fma@doe.carleton.ca> writes:

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

[snip]

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

Always compile your stuff with -Wall.  That should enable the warning.

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

One could argue that it is the cygwin environment that is buggy, since
it causes programs to crash, even though they run correctly on
solaris.

-- 
M�ns Rullg�rd
mru@users.sf.net

M�ns Rullg�rd wrote:

> Fred Ma <fma@doe.carleton.ca> writes:
>
> > 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:
>
> [snip]
>
> > 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.
>
> Always compile your stuff with -Wall.  That should enable the warning.
>
> > 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.
>
> One could argue that it is the cygwin environment that is buggy, since
> it causes programs to crash, even though they run correctly on
> solaris.
>
> --
> M�ns Rullg�rd
> mru@users.sf.net

Thanks for the tip about -Wall.  I never realized I had so much
problem with my code until I turned it on.  I thought I was being
high and mighty righteous-like with -pedantic, but it looks like
there is a higher righteousness.  Lots of good reading, too, of
the man page.

Despite the comment about buggy cygwin, I am all too thankful
that I can compare the execution on the two platforms (solaris
and cygwin).  Whenever they disagree, I may curse the heavens
for spending days to find out why, but it invariably uncovers a
big performance/correctness bug which really, really needs to
be fixed.

Fred

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

Fred Ma wrote:
> 
> Thanks for the tip about -Wall.  I never realized I had so much
> problem with my code until I turned it on.  I thought I was being
> high and mighty righteous-like with -pedantic, but it looks like
> there is a higher righteousness.  Lots of good reading, too, of
> the man page.

    Try using both -W and -Wall; the latter's name suggests
that it's enabling "all" warnings, but that's not so.

    Also, -O2 (or higher) in conjunction with these can
produce warnings that will help locate uses of uninitialized
variables.

    For code that can tolerate it (some perfectly good code
cannot), consider adding -ansi.

-- 
Eric.Sosman@sun.com

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

did you try the -W -Wall options? AFAIR, no return statement in a non-
void function *is* a candidate for a warning (e.g. the Borland compiler 
is especially smart to catch such execution path-related bugs), altough 
GCC by default is somewhat quiet

Fred Ma <fma@doe.carleton.ca> writes:

> Thanks for the tip about -Wall.  I never realized I had so much
> problem with my code until I turned it on.  I thought I was being
> high and mighty righteous-like with -pedantic, but it looks like
> there is a higher righteousness.  Lots of good reading, too, of
> the man page.

IIRC, -pedantic only makes gcc more fussy about standard compliance.
It still allows badly written code (apparently).

-- 
M�ns Rullg�rd
mru@users.sf.net

Eric Sosman wrote:

> Fred Ma wrote:
> >
> > Thanks for the tip about -Wall.  I never realized I had so much
> > problem with my code until I turned it on.  I thought I was being
> > high and mighty righteous-like with -pedantic, but it looks like
> > there is a higher righteousness.  Lots of good reading, too, of
> > the man page.
>
>     Try using both -W and -Wall; the latter's name suggests
> that it's enabling "all" warnings, but that's not so.
>
>     Also, -O2 (or higher) in conjunction with these can
> produce warnings that will help locate uses of uninitialized
> variables.
>
>     For code that can tolerate it (some perfectly good code
> cannot), consider adding -ansi.
>
> --
> Eric.Sosman@sun.com

Thanks, again, all.  I in for a bit of man page
reading and code cleaning.

Fred


> -------- Original Message --------
> Subject: Re: Should C/C++ compilers be smart enough to catch this???
> Date: Thu, 03 Apr 2003 23:23:26 GMT
> From: "KJK::Hyperion"
> Organization: [Infostrada]
> Newsgroups: comp.unix.programmer,gnu.gcc.help
> References: <3E8C8C4F.ABC60B0F@doe.carleton.ca>
>
> > 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,
>
> did you try the -W -Wall options? AFAIR, no return statement in a non-
> void function *is* a candidate for a warning (e.g. the Borland compiler
> is especially smart to catch such execution path-related bugs), altough
> GCC by default is somewhat quiet
>