lkml.org 
[lkml]   [1996]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: libc 5.3.6 BREAKS accelx!
Date
 > 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


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