witch_t *naviwe 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
they're all ints why did fds get left out of the typedef club qwq
humm@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
but yeah returning errno_t instead of 'int' would be a lot better
Laurent Bercot@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?
sarah tonin 
Sertonix@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
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
@ska @humm
> It's boilerplate,
how? it's not like you're typing more, just, a different identifier
> it makes the code less clear
disagree, `copy_range(fd_t in, fd_t out, size_t size);` is a lot clearer to me than `copy_range(int fd_in, int fd_out, size_t size);`
> and if I need to serialize it I need to add a sysdep test to know what size it is
nothing stops it from being specified as an `int` under the hood, and otherwise, `sizeof()`?
> It's boilerplate,
how? it's not like you're typing more, just, a different identifier
> it makes the code less clear
disagree, `copy_range(fd_t in, fd_t out, size_t size);` is a lot clearer to me than `copy_range(int fd_in, int fd_out, size_t size);`
> and if I need to serialize it I need to add a sysdep test to know what size it is
nothing stops it from being specified as an `int` under the hood, and otherwise, `sizeof()`?
@navi @humm I agree with almost everything here but if it's specified as an int under the hood, there's no reason for it not to be officially an int.
Boilerplate wasn't the right word; I rather mean burden of knowledge. Mental boilerplate.
Where I disagree is on our perception of clarity. copy_range(int fd_in, int fd_out, size_t size is clear enough to me, and doesn't burden the language with typedefs in order to say the same thing; documentation is obtained by clever use of (completely optional in a prototype) variable names.
Again, I think at this point it's just a question of taste.
kabel42@navi @humm @SRAZKVT That's exactly what I call boilerplate 😅 I don't see much value in this kind of macro that will never change. To me 0 in a fd context is just as readable as STDIN_FILENO while being shorter, so I prefer it - and if the fd context isn't clear, then the function needs to make it clearer. But I'm willing to accept it's a pure question of taste.
(Edit: typo)
@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 😝
Todd Knarr
Kirtai 🏳️⚧️
koorogi@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.
@ska @navi @humm Semantics. A file descriptor isn't an int, even if it's represented as one. And remember that whole mess when people's assumption that time_t was an int, specifically a 32-bit signed int, broke when we started using 64-bit systems? Using specific types helps emphasize that you can't make assumptions like that.
@ska
>I need to add a sysdep test to know what size it is
Now this is something that annoys be about all the typedefs for which it isn’t specified what type exactly they are: They don’t get corresponding macros in <limits.h> and <inttypes.h>. For errno_t and a hypothetical fd_t it’s “fine” (if mentally annoying) because you know they’re int, but how do you print a uid_t? In C89, converting to unsigned long and using %lu is safe. From C99 to C17, converting to uintmax_t and using %ju is safe. I’m guessing that the POSIX edition that rebases on C23 will keep uintmax_t safe by prohibiting uid_t from being an extended integer type, but maybe not.
@humm @navi That is honestly on the insanity of wanting to stick to the printf format despite having so many types. But yes, there is a real problem underneath, which is you don't know if all these types have the same size.
It would be funny if needing to convert to uintmax_t and using %ju was finally the loss of convenience that would make some people realize that oh, the printf format sucks, actually.
Cassandrich@navi pid_t and gid_t and uid_t are the consequence of historical disagreements about the underlying type and abstracting that away so systems with non matching definitions could both conform.
There has never been a disagreement on the type for fds.
clang-enby