we have pid_t and gid_t and uid_t but no fd_t

they're all ints why did fds get left out of the typedef club qwq
@navi we have errno_t as well and nobody uses it ever
@humm it's part of annex K iirc and things just don't implement annex K at all

but yeah returning errno_t instead of 'int' would be a lot better

@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?

@ska @humm

because it isn't any random int, it's a file descriptor, or an error, it has semantic meaning beyond the fact that it's represented by a number

you wouldn't do arithmetic with any of them, you wouldn't type a random literal to a function that takes a fd -- the fd represents and object, not a number by itself

@navi @humm Okay that makes sense, but it's in the nature of C to use int as a generic handle, and because it's an int doesn't mean you're going to do arithmetic with it. The integers I do arithmetic with are almost exclusively uint32_t, because 1. I want to know what their range is, and 2. in system programming, I never need negative numbers.

int is terrible for arithmetic for these reasons, and on the other hand it's a pretty good type for a handle: wide enough for all your needs and you don't really care if it's 32 or 64 bits, can use negative numbers for e.g. error values, has an ordering so you can use it as a key for sorting and logarithmic searches, etc.

This is a volcanic take, but I'd be okay with removing arithmetic operations from int (as long as you keep comparisons) and making it a handle-only type 😝

@ska @navi @humm "All the world's a VAX.". Don't fall into that trap. It's OK for code specific to one architecture, but for anything that has to work on multiple architectures you need to deal with possible weirdness. Big-endian is the least of it.
@tknarr @navi @humm Right, saying that types that are explicitly specified as integer types and typedef'd as int could be int instead is making assumptions that will break on some architecture, I'm sure 🤪
@ska @tknarr @navi @humm
There are some deeply bizarre architectures out there. It wouldn't surprise me at all.
@kirtai @ska @navi @humm I remember a while back looking up all the architectures Unix had been implemented on up through the late 90s or so. I though stuff like 36-bit int and middle-endian was the worst, but I was sadly mistaken.
@kirtai @tknarr @navi @humm I honestly don't think you can find me an architecture where an int is not an int, but don't let that discourage you from looking