[geeks] Compilation warnings...

[Charles Shannon Hendrix]

Sat, 25 Nov 2006 @ 21:03 -0600, Jonathan C. Patschke said:

> On Sat, 25 Nov 2006, Michael C. Vergallen wrote:
> 
> > Also is this a Solaris Compiler specific problem  or  is  it just that
> > code  written  for  G.C.C.  is looser in this and the Solaris compiler
> > stricter on those things ....
> 
> If restaurants cooked food the way gcc validates code, a "well done"
> steak would've passed through a kitchen while the grille was turned up,
> but you wouldn't be assured of much more than that.

Humorous, but exaggerated.

The primary problem is programmers that don't know their tools.

GNU C does have problems, but so do Sun's compilers, DEC's compilers,
and just about all of them.

In fact, as C compilers go, GNU C is better than the majority of the C
compilers created over the years.

As someone who came through the hell of C programming through the K&R ->
ANSI transition period, I tend to be wary in general.

Sun's compilers for years were pretty bad, and frequently had some
really difficult bugs to discover and get around. I think they are
probably OK right now, but haven't actively used them for 3 years now.

SGI's compilers seemed to work, and that's about all I can say, because
I never got into heavy duty debugging with them. Everything I wrote on
SGI worked, and I didn't happen to run into compiler bugs. Either they
are pretty good, or I just never hit the problems. I haven't read much
about their compilers either.

DEC's UNIX compilers were not bad, but one of my co-workers found some
math bugs in their C++ compiler for Alpha around 1997 that caused
*addition* operations to generate incorrect results. We ended up getting
a patch from DEC I believe.

The first time I ran into a GNU C bug was in 1994, when I was doing
embedded programming. I kept having control failures whenever my code
did a 16-bit write to hardware registers. Looking at the assembly
output, I realized it was doing 32-bit operations instead, which wreaked
havoc on hardware control code.

I reported the problem to Wind River, and they issued a fix and sent
me a new compiler on tape.  FSF/GNU ignored my bug report.

I've read a bit of the GNU compiler code, and it looks pretty nasty to
me. Stallman seems to delight in needless complexity. I've read where
some of the GNU compiler maintainers find it a very hard system to work
with.

Of course, there aren't many alternatives, and many of them are quite
expensive.

I wish Intel would just release their compilers, but so far they just
release part of their toolset and its not totally free.  It's also
pretty obvious they aren't going to be gung ho to support AMD-only
code generation.

Incidentally: does anyone know what AMD uses in-house?

> GCC isn't just poor at making sure code adheres to even the loosest
> interpretations of the language standards, but also extends the
> language in ways that create entirely new[0] language constructs that
> aren't valid on other compilers.

True.

There are two big problems here. Some extensions are on by default, and
the manual is typical GNU/FSF, which means it is outdated, incomplete,
and often just plain wrong.

> [1] Or, as seems too often the case, the maintainers released the code
>      because it compiled with warnings instead of errors.

It's amazing how many major errors go away when you fix those "harmless
warnings".

People not fixing them and teams/bosses that won't insist on keeping
builds clean drive me nuts.

I also miss some of the features of the mainframe and minicomputer
compilers that I started out on.

-- 
shannon "AT" widomaker.com -- ["Castles are sacked in war, Chieftains are
scattered far, Truth is a fixed star, Eileen aroon!" -- Gerald Griffin]