I’ve had a small library for tcp socket handling and polling on Windows, and the system library for windows is very straightforward, pretty much all the foreign procs with the same parameter types and constants you’d expect. With Linux, it seems there is an attempt to wrap syscalls with native Odin procs and enums which is also straighforward, until you hit proc groups.
I’m gonna take fcntl and setsockopt as examples but it probably apply to others. Both of them have a few overloads based on the type of the command/level parameter, but because they’re essentially the same enum, it forks into distinct types and define a few constants such as F_GETFL or SOL_SOCKET that need to be used (?) to trigger the correct overload. So now instead of using linux.setsockopt(fd, .SOCKET, opt, val), you’d be using linux.setsockopt(fd, linux.SOL_SOCKET, opt, val) or linux.setsockopt_sock(fd, .SOCKET, opt, val). And I don’t have a problem with one or the other. It is just that when a few functions use implicit enum notation, it takes a while to find which ones don’t, and it becomes an annoying back and forth into the library’s source. For all purposes I wouldn’t have a problem with having only specialized functions such as linux.setsockopt_sock(fd, opt, val), linux.fcntl_getfl(fd), but I think it’s more appropriate to have something similar to sys/windows, in which you’d directly reference constants such as win.SOL_SOCKET and win.IPPROTO_IPV6.
Let me know your thoughts on this. I was thinking on maybe doing a PR to help streamlining it but I’m not sure whether it’s even considered a problem, or which direction it should go.
EDIT: Just for completion, I actually hadn’t tested linux.setsockopt(fd, linux.SOL_SOCKET, opt, val) so I just now found out that it doesn’t seem to help with the correct overload resolution and will yield an error if you try to pass something like .REUSEADDR as the opt parameter.