To ANSI or not to ANSI (was: Re: Just a minor new twist on free())

[Conor P. Cahill]

In article <PDS.90Oct8101336 at lemming.webo.dg.com> pds at 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