Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <102@bbxsda.UUCP>
Date: 18 Sep 89 16:03:56 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <1989Aug17.005548.745@twwells.com> <16022@vail.ICO.ISC.COM> <248@seti.inria.fr> <10817@riks.csl.sony.co.jp> <254@bbxeng.UUCP> <10829@riks.csl.sony.co.jp>
Reply-To: scott@.UUCP (Scott Amspoker)
Organization: /etc/organization
Lines: 50

In article <10829@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes:
>
>>6)  Therefore, we all agree to avoid those compilers thus driving the
>>    vendors out of business and we have nothing to worry about.
>
>If you wish to personally boycott all compilers that do optimization,
>feel free.
>

Thank you, we do feel free.  We have over 60000 lines of 'C' code that
runs unmodified and over 40 different systems (different OS and
hardware archetecture).  The nature of our application is such that
we do a *lot* of pointers-to-structures (so yes, we benifit from
pointer optimization).  In order to earn a living and feed our families
we have had to make sure our C code is as safe and conforming as possible 
(no tricky stuff).  I would hazard a guess that many other software 
developers would get bit long before we do (based on some of the postings
I've seen in this group).

However, once in a blue moon a C compiler comes along that appears to 
go out of it's way to make trouble.  We have turned down brain-damaged 
compilers before and it hasn't hurt us one bit.  Although I have never seen a
compiler/architecture combination that has unsafe pointer compares
I have seen some other bizzare things.  Fortunatly, these things happen
very rarely and *never* with a well known company (although well-known
companies do have bugs).

For example, since we run on Intel cpu's we use the "near" and "far"
keywords.  When we compile on other environments we must remove
those keywords.  We do so with:

#define near
#define far

So far, so good.  Now along comes a C compiler that doesn't support
"near" and "far" but also WON'T LET US REDEFINE NEAR AND FAR either.
(because near and far are reserved).  For crying out loud!  In this case
it was easy for us to do the port anyway because it required a simple text 
string substitution across all of our source.

Perhaps we will run into something that is the result of some obscure
assumption we made that, technically, is non-comforming.  While we
would admit that we were wrong we would also remind ourselves that we
have been doing extremely well so far and wouldn't necessarily take
the expense to re-write all our code.  That's life.  I realize that
this group is much more academic.  If you want to sell a C compiler
in today's market you better make sure it can run a lot of existing code
without any trouble.  Where one draws that line is a matter of personal
taste.  I personally don't think that every little bit of optimization
has infinite value when there are so many other things to consider.