Xref: utzoo comp.lang.c:32744 comp.std.c:3735
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: To ANSI or not to ANSI (was: Re: Just a minor new twist on free())
Message-ID: <1990Oct09.132005.8435@virtech.uucp>
Date: 9 Oct 90 13:20:05 GMT
References: <PDS.90Oct8101336@lemming.webo.dg.com>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 43

In article <PDS.90Oct8101336@lemming.webo.dg.com> pds@lemming.webo.dg.com (Paul D. Smith) writes:
>I do, however, have a new point I'd like to take up some bandwidth
>on: basically, I got a lot of responses stating that free(NULL) should
>not be used because, although it *is* ANSI compliant, it is not
>backward portable.
>
>My question is: since we now have a standard (whatever you may think
>of it, it is an internationally accepted definition of the C
>programming language), why do we have so much reluctance to embrace
>it?  In particular, how can you justify labelling a program
>"non-portable" if it follows the ANSI standard?

The big question is:

	How does it effect the performance, reliability, and/or readability
	of your code to make it "portable" to non-ANSI compilers?

Since non-ANSI compilers are somewhat prevalent at this time you must
take that into consideration.

Not calling free(ptr) when ptr==NULL by checking the ptr with an if, will:

	1. probably improve performance in most cases
	2. be just as reliable as just calling free() with a null ptr
	3. be just as readable.

So IMHO you shouldn't use this feature.

However, this is not a blanket statement that should be conscrued to mean
that you shouldn't use any ANSI enhancements.  For example, using
function prototypes will:

	1. have no effect on performance.
	2. be more reliable.
	3. be just as readable.

So use them and add an #ifdef to conditionally use them if you have an
ANSI compliant compiler.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170