[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20160413133919.GO25745@example.net>
Date: Wed, 13 Apr 2016 15:39:19 +0200
From: u-uy74@...ey.se
To: musl@...ts.openwall.com
Subject: (OT?) replying two years later (was: Removing sbrk and brk)
This is not about musl but about a musl-compatibility of some
respectable software :)
2014-02-21 23:34 GMT+1 Daniel Cegiełka wrote:
> 2014-02-21 18:09 GMT+01:00 Rich Felker <dalias@...ifal.cx>:
>
> > Then it didn't work before either; it was silently corrupting memory.
> > The only difference now is that you know that it's not working.
>
> Thank you for your response and I understand the reasons.
> In my free time I will try to fix ex/vi ...
FWIIW.
I did not find anyone else having built a working ex-vi with musl.
As a quick hack, given the absence of threading:
an additional file sbrk.c (attached)
and "make MALLOC=sbrk.o" do the trick for ex-vi, at least on ia32.
(I also removed the "poolsbrk(0);" call from ex.c and exrecover.c,
instead of adding a dummy function. A more elaborated fake sbrk might
use it for initialization of course.)
May be this will be useful to someone, while building old stuff.
This may also further mitigate the motivation/need for sbrk() in musl.
Allocating "a lot of" unused memory should not hurt much on modern Linux
with MMU, adding support for negative increments is straightforward
if there are programs making heavy use of such a feature.
Cheers,
Rune
View attachment "sbrk.c" of type "text/plain" (598 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
