Messages in this thread | | | Date | Fri, 15 Mar 1996 23:06:51 -0500 (EST) | From | Jauder Ho <> | Subject | Re: 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
| |