they're all ints why did fds get left out of the typedef club qwq
@navi @humm Why do yall think that the multiplication of integer types is a good thing?
It's boilerplate, it makes the code less clear, it bloats header files, and if I need to serialize it I need to add a sysdep test to know what size it is. And the benefits of having specific integer types are dubious at best, I've never seen a strong argument for them.
What makes you want fd_t and errno_t over int or, if anything, int32_t?
@navi @humm @ska For functions returning an fd or -1 on error, I see code check fd >= 0. Or code which checks fd <= 2 to see if it's one of the standard streams. close_range (which I think is a misfeature) works on fds >= first and <= last. poll allows you to easily disable polling one of the fds in the array by setting it to ~fd.
All of these require fds to be a numeric type if not an integer type.
@koorogi @navi @humm I see these more as shortcuts than "official" ways to do things. For errors, there could be an FD_ERROR special value. For standard streams, there could me a macro checking them. For close_range, well, we agree it should not exist. For select (not poll, which takes a list of struct pollfd!) there could be macros to enable or disable an individual fd.
I mean, I agree, fd being a numerical type is practical and I like the fact that it's an int, but I don't think your arguments are the deciding factor.
@koorogi @navi @humm No, they're comparison operators, which have a much lighter requirement than arithmetic operations: they only need an ordered set, whereas arithmetic needs a mathematical group/field/ring.
Substraction + sign check requires a stricter hypothesis than direct comparison between two elements does.
Of course, on a computer, this mathematical difference doesn't really matter, because it's all integers inside anyway, but if we're writing a spec, it's worth knowing how strong you want the guarantees to be.