Wishlist: the arc4random family (would also put up with it being in POSIX), strlcat and strlcpy (yes, glibc, just for you), getline (fgets sucks), reallocarray and recallocarray, that signed integer overflow becomes at least implementation-defined rather than pure undefined behavior, ideally fix the notion of locales and guarantee (u)int8_t == unsigned char if (u)int8_t exists (lots of code actually relies on that).
getline is POSIX. If you want to see arc4random in POSIX, you should write to the Austin Group mailing list: austin-group-l@opengroup.org. They also have public biweekly meetings you can attend and present your case at.
getline is POSIX, but not C. I feel like the functionality is so fundamental to writing C as securely as the language allows that it ought to be promoted to being in the C standard.
arc4random is in complete POSIX limbo as far as I can tell. First started as a rename to posix_random[1] and then OpenBSD slammed the door shut by withdrawing it and now we're at risk of getting the worst of both worlds with Linux's getrandom[2].
arc4random() and getrandom() are orthogonal. The former generates cryptographical pseudorandom data in-process, periodically re-seeding from an OS entropy source. The latter in an interface to an OS entropy source.
Yes, they are orthogonal. However, chances are POSIX can only be convinced to add one. And I'd rather they add the one that can't be misused by a programmer.
FILE is part of the standard, see 7.21.3 and e.g. 7.21.5.3. Section numbers as per C11 latest public draft; I don't have two hundred bucks to spend on an actual copy of the standard.
No, char was 8 bits on the PDP-11, which was a 16-bit little-endian machine. (not middle-endian unless you count the typical compiler being weird with 32-bit values on the 16-bit little-endian hardware)
C didn't run on the PDP-7.
Being either 7-bit or 9-bit would be a choice for 36-bit hardware. Wikipedia's list of 36-bit hardware is: MIT Lincoln Laboratory TX-2, the IBM 701/704/709/7090/7094, the UNIVAC 1103/1103A/1105 and 1100/2200 series, the General Electric GE-600/Honeywell 6000, the Digital Equipment Corporation PDP-6/PDP-10 (as used in the DECsystem-10/DECSYSTEM-20), and the Symbolics 3600 series.
Sorry, it should have been PDP-10, the point stays the same -still one of the founding architectures of original UNIX. PDP-11 used 16-bit words and 8-bit bytes.
For once I agree with the glibc developers: strlcat and strlcpy are bad interfaces.
Truncation can cause security bugs, and it is generally awful behavior. There is no silver bullet here: the programmer must not be a dummy about buffer sizes. Pretending otherwise is unhelpful.
Even better (someone please correct me if necessary) why isn't the very concept of "undefined behavior" completely removed? What good does it accomplish in a language?
Allows the compiler to assume certain cases where undefined behavior would appear are unreachable and make optimizations based on trusting that those cases will not occur.
If uint8_t exists, then I believe the following ought to be true:
1. CHAR_BITS == 8, and
2. the compiler is required to make uint8_t an alias of unsigned char.
Point 2 is there so that you can cast to uint8_t safely, which some cryptographic code tends to rely on. If uint8_t is just any integer type, there's no safe cast to uint8_t due to strict aliasing rules[1]. That's what I want to fix. CHAR_BITS == 8 if uint8_t exists is just a collateral.
It follows from the fact that sizeof (char) == 1 and CHAR_BITS >= 8 that sizeof (char) == sizeof (uint8_t), but strictly speaking I don't know that the standard guarantees that uint8_t is an alias of unsigned char and could as well be a distinct type.
