A tale of two C's.

[Tom Stockfisch]

In article <474 at bnlux0.bnl.gov> drs at bnlux0.UUCP (David R. Stampf) writes:
>>In article <154 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
>>>When portability is not an issue, a programmer should be free to use
>>>his or her own implementation of a standard library function.

>I have frequently found the need to chuck some of the standard library
>routines in favour of locally written routines...
>(in one example I didn't need the full generality that malloc
>gave me, since I was always allocating fixed length blocks, so I wrote my own
>that took advantage of the machine that I was running on (Mac)...

Why would you want to call a function "malloc()" if it does not do the
same thing that the malloc(3) man page says malloc() does?

>... I wanted the
>code to be portable to a wide variety of machines that may have very different
>architectures...
>In these cases, you cannot export your custom library routines - but have to
>allow the default library to kick in.
>	< dave.

So write something like

	# ifdef MAC
		BLOCK_T *	/* new memory */
		block_alloc( nblocks )
		{
			[fast, unportable stuff here]
		}
	# else
		BLOCK_T *	/* new memory */
		block_alloc( nblocks )
		{
			return	(BLOCK_T *)malloc( nblocks*sizeof(BLOCK_T) );
		}
	# endif

I would find it *very* confusing to read code in which malloc() (or any
other standard library function) did something besides/instead of what
it is supposed to.
-- 

|| Tom Stockfisch, UCSD Chemistry	tps at chem.ucsd.edu