use of malloc.h in KDE
David Leimbach
leimbacd at bellsouth.net
Fri Nov 22 12:32:54 GMT 2002
Hi Andy,
Best I can tell is there is no good reason to ever use malloc.h anymore
since the correct C standard place to place malloc's prototype is
stdlib.h.
I have had quite a few hellish experiences and the opportunity to beat
some
of my coworkers with a clue-bat on some occasions on this matter.
KDE should probably not use malloc.h as its not portable and any C
implementation
that does not have malloc in stdlib.h is just non-standard and should
be handled
as a corner case probably. IMO
Dave
On Friday, November 22, 2002, at 02:51 AM, Andy Fawcett wrote:
> Hi,
>
> I just installed FreeBSD 5.0DP2, which is basically a developer preview
> of the upcoming version, due for release next month.
>
> I'm running test builds of KDE CVS on it, and one thing that has
> cropped
> up in a few places is the inclusion of <malloc.h>.
>
> Previous versions of FreeBSD's compiler have generated a #warning
> saying
> that this is deprecated, and that <stdlib.h> instead.
>
> The new version throws a #error, with the same basic message, causing
> some parts of KDE to fail to build.
>
> So...
>
> I am wondering how best to fix this in KDE, as I (and the rest of the
> KDE/FreeBSD team, as well as others) really would like to see FreeBSD
> 5.0 as a supported OS, given that it is being released soon.
>
> I could wrap the #include like this:
>
> #if !defined(__FreeBSD__)
> #include <malloc.h>
> #endif
>
> but that is so messy. I looked to see if there was an auto* check for a
> _working_ malloc.h, but I cannot find one.
>
> I don't want to commit stuff that is messy, but are there any better
> alternatives?
>
> Regards,
>
> Andy
>
> --
> Andy Fawcett | "In an open world without walls and fences,
> andy at athame.co.uk | we wouldn't need Windows and Gates."
> tap at lspace.org | -- anon
>
More information about the kde-core-devel
mailing list