2021-06-05 edeemer: replace sbrk(3) with malloc

[josephholsten]

See especially the malloc based sbrk(3) replacement in:

• https://github.com/traditional-vi/edeemer-ex-vi/commit/b12bce6a314f9e632d1ed7bd76540628969dc60e
• https://github.com/traditional-vi/edeemer-ex-vi/commit/89e7021cf2599d30d3d064ce3e6fa36b707466dd

[josephholsten]

See musl approach from https://github.com/ryanwoodsmall/heirloom-ex-vi/commit/64a49ecbd624453e9e1e87e3fed599ccbb60e257

[josephholsten]

See https://github.com/edeemer/ex-vi/commit/b12bce6a314f9e632d1ed7bd76540628969dc60e

[josephholsten]

This is quite important to support FreeBSD on aarch64, riscv which have not implemented sbrk()

[josephholsten]

Looks like the musl sbrk in @ryanwoodsmall branch is still relying on the brk syscall, which is not implemented in FreeBSD aarch64: https://cgit.freebsd.org/src/tree/lib/libc/aarch64/Symbol.map?id=0b51c11a0e75197a8791f6e635a08e36d5a42bd5

[josephholsten]

Looks like @edeemer is using a pool from malloc, so this should be preferred. I’ll test on FreeBSD now.

[ryanwoodsmall]

wrapping malloc is the right move here. my changes were as minimal as possible to get ex-vi building and functional with musl on linux and brk/sbrk were the path of least resistance.

[edeemer]

The problem with malloc pool is that its address could change after realloc. So here comes the hacky part with shifting pointers to the pool. While I haven't seen any bugs (besides fixed in the second patch) for nearly-everyday use of my fork linked with musl, there was a rare case of segfault while editing file on OpenBSD/amd64. AFAIR, it was arising after longjmp(3). Unfortunately, I have no access right now to the OpenBSD machine to get a list of actions to reproduce and even more hacky patch.