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

[Kris Kennaway]

Luigi Rizzo wrote:
> 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...

It's a trivial fix.  Just do it instead of over-engineering a solution :)

Kris