lkml.org 
[lkml]   [1996]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: libc 5.3.6 BREAKS accelx!

well the problem is that accelx has it's own malloc optimized for
graphics type stuff. and it has to keep the name malloc to keep
compatibility with the X consortium... it is kinda bad to have to have
everyone change their implementation of malloc broken or not because of
the way how libc handles things.. to me that just seems a tad draconian

--Jauder

On Fri, 15 Mar 1996, David Holland wrote:

> > I think it is great that we have a faster and better malloc for libc but
> > I think it should not be at the expense of compatibility. I think that we
> > should all still be able to write our own mallocs if we want to and not
> > have libc break it. So if we can find a way to still use dl-malloc and
> > have other mallocs coexist with it, that would be great.
>
> You're missing a point, namely, that any replacement malloc that
> doesn't implement valloc has always been broken; it's just that the
> breakage is only visible with the new malloc.
>
> Suggestion: all the places in libc that call valloc should free the
> memory with vfree(), which is to be a new function.
>
> This removes the problems with calling __libc_valloc directly. There
> is still a cost in compatibility, this time probably with POSIX
> (someone who has the relevant POSIX want to share what it says about
> valloc, or tell us it doesn't?)
>
> --
> - David A. Holland | Number of words in the English language that
> dholland@hcs.harvard.edu | exist because of typos or misreadings: 381
>
>


.sig under construction



\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.049 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site