Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!comp.vuw.ac.nz!comp.vuw.ac.nz!mark
From: mark@comp.vuw.ac.nz (Mark Davies)
Newsgroups: comp.lang.c
Subject: Re: null args to macros in ANSI C
Message-ID: <1989Oct13.003537.4584@comp.vuw.ac.nz>
Date: 13 Oct 89 00:35:37 GMT
References: <1989Oct9.195333.2544@comp.vuw.ac.nz> <11247@smoke.BRL.MIL>
Sender: news@comp.vuw.ac.nz (News Admin)
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Lines: 44

In article <11247@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1989Oct9.195333.2544@comp.vuw.ac.nz> I wrote:
>>Is objecting to the following bit of code an ANSI'ism?
>>#define mem_alloc(s) malloc(s)
>>extern char *mem_alloc();

>No, it's simply incorrect use of C, and pre-ANSI implementations should
>also complain about it.

>Note also that malloc() should NOT be declared by the application under
>a standard-conforming implementation; instead #include <stdlib.h>.  The
>function returns void* in conforming implementations.

>I don't know why you want to rename malloc, but
>	#define mem_alloc malloc
>will do it correctly.

I don't normally. Sun did.  The actual bit of code this occured in was part
of sunrpc.

rpctypes.h includes the following bit of code

	:
#ifndef KERNEL
extern  char    *malloc();
#define mem_alloc(bsize)        malloc(bsize)
#define mem_free(ptr, bsize)    free(ptr)
	:

then xdr_reference.c does the following

	:
#include "rpctypes.h"   /* <> */
	:
	:
char *mem_alloc();
	:

Just another example of Sun writing bogus code it seems.

mark
--
 mark@comp.vuw.ac.nz    |
 ...!uunet!vuwcomp!mark |				DEV_BSIZE forever!