[ILUG] gcc optimisation weirdness?

[Shane Dempsey]

Hiya Kenn, 
Point taken. It is a valid and standard alternative
to using the kind of masks that I normally use. 
It might even be a lot tidier. I guess that I was 
talking from a windows-founded ivory tower
where we use glorious macros for these kind
of things. 

I'd be very interested if anyone could test the following code
for me using gcc. 
// ===================================
// AFAIK this shouldn't compile but VC++ thinks this 
// is just peachy. 

struct PreludeToFailure(
    PreludeToFailure( int stuff ) : _internalStuff( stuff ) { }

    int _internalStuff;
}

main ()
{

 // do some stuff here
// ...
 return 0;

}

// ===================================

This compiles under VC++ event with the strict ANSI compliance
turned on ( -Za option for the MSVC compiler )
despite ANSI C requiring   an int return type from main.
The program crashes - no shit - but still compiles as
the struct takes an int in the constructor. 

Just wondering if gcc is as badly behaved. I doubt it.

    ...shane


-- 
######################################
Shane Dempsey -         sdempsey at tssg.wit.ie
TSSG Researcher -      http://www-tssg.wit.ie

( 0x2b | -0x2b == 0xff ) ? printf("that is the question);
####################################### 
---------------------------------------------------
From: "Kenn Humborg" <kenn at linux.ie>
To: "Shane Dempsey" <sdempsey at tssg.wit.ie>
Cc: <ilug at linux.ie>
Sent: Wednesday, May 10, 2000 9:52 PM
Subject: Re: [ILUG] gcc optimisation weirdness?


> On Wed, May 10, 2000 at 08:59:58PM +0100, Shane Dempsey wrote:
> > Also        ' : '
> > ( as previously stated )
> > is definitely non-standard and pretty damn horrible. When
> > space gets that tight you should just right the fscking thing in
> > assembler.
> 
> It's not simply a space issue.  Whatever about disk space being
> cheap, bandwidth isn't in a lot of cases.  I don't think you'd
> like it if all the option and flag bits in your TCP and IP headers
> took up one byte each...
> 
> Not to mention dealing with hardware.  No hardware designer is
> going to waste bus bandwidth and I/O address space by dedicating
> whole bytes (or larger) to fields that can be held in a single
> bit.  (Says me while I'm editing a header file in another xterm
> with definitions for old VAX serial I/O chips...)
> 
> Later,
> Kenn
> 
>