best way to work around <malloc.h> vs <stdlib.h> ?

[Luigi Rizzo]

On Tue, Aug 19, 2008 at 01:12:37PM -0500, Jeremy Messenger wrote:
> On Tue, 19 Aug 2008 12:26:31 -0500, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
> 
> >A fair amount of third party software in ports still uses <malloc.h>
> >which in our system is like this:
> >
> >	/* $FreeBSD: src/include/malloc.h,v 1.5 2001/11/07 23:14:31 obrien 
> >	Exp  $ */
> >	#if __STDC__
> >	#error "<malloc.h> has been replaced by <stdlib.h>"
> >	#else
> >	#include <stdlib.h>
> >	#endif
> >
> >What is the best way to disable the error without an
> >explicit patch (there are over 200 patchfiles in ports
> >just doing that) ?
> 
> I think patch it is best, because if I understand it corrects is that  
> malloc() in stdlib.h is standard of ANSI C. Correct me if I am wrong.  
> However, I don't see anything wrong with patch. You can simple use  
> wildcard (*.c) or use find(1) to find files to replace the malloc.h ->  
> stdlib.h by use REINPLACE_CMD without have to create multi-file patch.

i am not questioning the correctness of using stdlib.h rather than malloc.h,
nor the fact that if the upstream is cooperating, one surely should pass patches
upstream.

However this malloc.h (and missing sys/types.h -- there's another
200+ patch files doing just that) seem to be very common porting
problem and so it would be issues and thought it could be nice to
find a fix that addresses those kind of problems.

Wonder if a -I/usr/local/questionable-programs/include approach
could be used to wrap the handful of system headers that cause problems...

	cheers
	luigi