Path: utzoo!attcan!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.lang.c Subject: Broken compilers Message-ID: <1988Nov12.164140.2565@ateng.ateng.com> Date: 12 Nov 88 21:41:39 GMT References: <8810111934.AA21941@ucbarpa.Berkeley.EDU> <8308@alice.UUCP> <23933@wlbr.EATON.COM> <1988Oct19.192548.28438@ateng.ateng.com> <35 <35569@XAIT.Xerox.COM> Organization: A T Engineering, Tampa, FL Lines: 28 According to g-rh@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 or A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.