Broken compilers

[Chip Salzenberg]

According to g-rh at XAIT.Xerox.COM (Richard Harter):
>	More to the point, if your coding practices use constructs and
>techniques that break compilers, you are laying problems up for yourself
>and others in the future.  

It's true that all compilers are broken to some extent.  The real question
is what to do about it.  I personally write C -- using the *entire* language
-- and install workarounds later as needed.

There is no way to predict compiler bugs, especially in view of buggy
compiler updates.  Avoiding things that *might* break is a shell game that
can never be won.  I, myself, don't play the game.

>Writing clean C is no harder than writing dirty C.
>But the price of writing dirty code is high -- debugging dirty code is a
>real pain, and it is a gratuitously assumed cost.  

Code that uses the *entire* language defined in K&R is not "dirty" for it.
Further, the coding style that Mr. Harter calls "clean" I would call
"running scared".  I can imagine Mr. Harter considering a nice C trick:
"I know that K&R says it's okay, but what if some compiler doesn't like it?
I'd better not risk it."

Personally, I write C, not a subset thereof.
-- 
Chip Salzenberg             <chip at ateng.com> or <uunet!ateng!chip>
A T Engineering             Me?  Speak for my company?  Surely you jest!
	   Beware of programmers carrying screwdrivers.