Subject: Re: FreeBSD misses malloc.h
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-pkg
Date: 07/23/2003 17:21:43
[ On Wednesday, July 23, 2003 at 13:43:34 (-0400), Todd Vierling wrote: ]
> Subject: Re: FreeBSD misses malloc.h
> You'd think that software authors would learn about the error of their ways
> when things stop compiling, too.  <malloc.h> has been obsolete for literally
> *decades* at this point.

I'm sure that's what drove the FreeBSD folks to try what they're trying.

However I'm not sure that breaking 3rd-party code in such a purposeful
and drastic way will win friends and influence neighbours.

(it also seems they've got the sense of what __STDC__ means backwards --
i.e. it's something the compiler tells the application, not the other
way around)

Now on the other hand if there wasn't any <malloc.h> at all (instead of
one that purposefully causes compile time errors) then I think 3rd party
developers would simply accept the fact that after Release-BLAH of
whatever platform it is they simply don't have such a file to include
and if they really truly do need to support any ancient antique systems
which require <malloc.h> to be included then they would hopefully adjust
their code to deal with the situation in a more portable manner.

The only unfrotunate thing is that this won't necessarily help any 3rd
party developers learn that something like <malloc.h> was never needed
on some platforms.

> But then, things won't stop compiling on many operating systems unless you
> do something standards-sane like defining _POSIX_SOURCE.  8-)

Indeed!  ;-)

unfortunately even defining _POSIX_SOURCE doesn't mean an application
won't be so lame as to try to include a non-standard heade (or worse).

Maybe it would be nice if the pre-processor simply refused to see
non-standard headers (at least all those without a "/" in their name)
whenever some standards-restricting macro like _POSIX_SOURCE is defined.
(I haven't really though through all the consequences of this idea fully
but it's not the first time I've thought there should be some way to
restrict the visibility of headers when a user claims to only want a
certain specified API.)

						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>