Path: utzoo!mnetor!uunet!husc6!think!ames!oliveb!pyramid!prls!philabs!sbcs!bnlux0!drs
From: drs@bnlux0.bnl.gov (David R. Stampf)
Newsgroups: comp.lang.c
Subject: Re: A tale of two C's.
Message-ID: <479@bnlux0.bnl.gov>
Date: 30 Apr 88 03:30:12 GMT
References: <152@ghostwheel.UUCP> <7691@brl-smoke.ARPA> <154@ghostwheel.UUCP> <7750@brl-smoke.ARPA> <474@bnlux0.bnl.gov> <193@chem.ucsd.EDU>
Reply-To: drs@bnlux0.UUCP (David R. Stampf)
Organization: Brookhaven National Lab., Upton, N.Y.
Lines: 85

In article <193@chem.ucsd.EDU> tps@chem.ucsd.edu (Tom Stockfisch) writes:
>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?
>

Of course I wouldn't want to define a function called printf that allocates
memory, or sin that did sqrt.  The point is that one might like to have
a more efficient version (for the application at hand) than the malloc
provided in the library.  My versions of malloc *always* behaved exactly
like the malloc(3).  It might be totally acceptable to have a routine called
emalloc() or must_malloc() or some such that *must* allocate memory and in
facts checks the return value for you.


>>... 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
>


This is better???  I find it 1) ugly, 2) error prone (when you start to write
code for two different machines using ifdefs, there is a tendency to debug
only one branch of the #ifdef and leave the other for some other character
to find)  and 3) makes the malloc version even less efficient - now you make
2 function calls per malloc rather than one.  Finally, when the programmer
is working on a remote section of the code he is likely to either forget about
this function and call malloc, forget what the new program was called, or
see a reference to block_malloc, and not really associated the malloc function
with it.  Also, it is very unlikely that a programmer would go to the trouble
of making a new manual page for block_malloc.


>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


Me too.  That's why I would want it to perform the save function as malloc,
only to do it in a slightly different fashion.

	< dave


*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *
*fodder for the news program *