Open XeonG opened 3 months ago
(replied by email yesterday but it didn't appear here in the tracker, so I'm duplicating it)
reallocarray() is present on glibc >=2.26 and originated from OpenBSD. SOCK_CLOEXEC is a Linux and BSD extension that is a few years old as well. MSG_DONTWAIT is around since Linux 2.2 (from the 90s) and is also present in the BSDs. How old is the system that you're trying to build on, and what OS is it running?
according to the issue he opened on my repo, he's using a mac, and it seems likely he won't respond anymore.
Thanks, I'll close out the bug then. I would have expected Mac to more closely conform to the BSDs, but it's not a platform that I can easily test against, anyway.
I didn't see it, yes it was on a OSX Mac is always updated but I'm not into build scripts, if there is something I can do to update the build pipeline let me know as I'm trying to get this working.. @rofl0r just seen the reply
It's an issue of OSX lacking features that are present on other commonly-used platforms and isn't simply a build system fix. Most of these have been around for quite a number of years and I'm surprised OSX lacks support.
For muonsocks, you'd need to:
1) Reimplement reallocarray() or find a library that provides it (maybe libbsd?). The tricky thing in implementing reallocarray() is avoiding UB from integer overflows that is easiest to do by using compiler built-ins (present on gcc and clang or standardized in C23) or relatively tricky checks written in pure pre-C23 C.
The other missing syscall flags are used for various reasons, often to avoid syscall overheads.
2) MSG_DONTWAIT is used so that reads are non-blocking while allowing writes to block; this allows the buffer size within muonsocks to be controlled and bounded and also avoids calls to poll(). This is a non-trivial change and requires restructuring the core loop that proxies reads and writes between client and server, and would come at the cost of more syscalls [both fcntl() per-connection and more poll() calls for every read/write cycle]. I don't know if a similar but differently named flag exists on OSX, but if it did, that would also be a solution.
3) SOCK_CLOEXEC is a way to avoid another syscall, it could be worked around but would have to be conditional to OSX as it's a performance pessimization on other platforms.
I think it's probably better to use microsocks instead, as these changes would remove a lot of the optimizations that have been done in muonsocks.