C and Unix APIs [was: [PATCH] Improve mutt's random data generator.]

This is a digression, irrelevant to Mutt getting random numbers.

On Thu, Apr 23, 2026 at 22:58 +0200, Alejandro Colomar via Mutt-dev wrote:

>> That can only work for signed types. In an unsigned type, all possible
>> values are valid lengths, so unsigned types should not be used for that
>> two-meanings hack.
>
>Not true.  I certainly prefer signed integers for most stuff, but
>unsigned types wider than int also work well.  And for example, the
>ISO C standard has a few functions that return size_t with an error code
>of -1.  For example, see mbrlen(3).

Sure, practically, we get by with that stuff, and it's been in Unix and 
the C library for a long time, but if the value is unsigned, it's not 
conceptually clean. Conceptually, all possible unsigned values are 
valid buffer sizes, but here one of them has been redefined to mean 
something else.

Here's getrandom():

ssize_t getrandom(void *buf, size_t buflen, unsigned int flags);

The return value is either the number of bytes written into buf, or -1 
on error. On error, the global variable errno is set with an error code.

Hypothetically, I'd be happier with

int getrandom(void *buf, size_t buflen, size_t *n, unsigned int flags);

The return value is an errno code, which is 0 on success. The number of 
bytes returned in buf is returned through the pointer argument "n". 
That way there isn't a single value with two meanings, and we don't 
have to compare anything to -1. (This also bypasses the global variable 
errno; that global variable is less than ideal for other reasons. 
Again, this is hypothetical.)

The fundamental Unix system call read() is similar: number of bytes 
read and an error flag are combined in the return value, and it can set errno.

Obviously those functions won't change, and read() has existed since 
the beginning of time, but that doesn't mean the API is perfect.