Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <193@chem.ucsd.EDU>
Date: 27 Apr 88 21:01:41 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA> <474@bnlux0.bnl.gov>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Organization: Chemistry Dept, UC San Diego
Lines: 42

In article <474@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes:
>>In article <154@ghostwheel.UUCP> ned@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@chem.ucsd.edu