Another minor thing I think belongs in the C standard is bswap. For such a common operation that's necessary for portable code, I personally don't understand why it hasn't been defined in either the C or C++ standard.
Currently, the only compiler I'm aware of that optimizes a bswap correctly is LLVM, which leaves a lot of code in the cold Aside from requiring people to write their own bswap, which is fairly maligned [1] for good reason, It leaves out a reasonably important optimization or potentially requires excess maintenance (platform libs, intrinsics, etc...) for people who do need portable code (the main reason for bswap).
I think languages are starting to take the place of platform independent interfaces, and my personal opinion is that bswap is fairly low hanging fruit. Given that one of the stated goals of C is portability, I think it fits well within the mandate.
This doesn't say anything about pointer arithmetic on pointers to raw memory though. For example, using an mmap file, there isn't any object, and there aren't any bounds.
I can see that a non-linear address space doesn't imply a strict weak ordering, but this still seems to be an implementation defined detail. It doesn't imply anything about pointer arithmetic overflow.
For example, consider x86 segments. Is there a reason why you would use negative offsets? Given a segment address, the number of representable values is identical whether the offset is strictly positive, or negative with a shifted segment address (assuming two's compliment).
Accessing beyond bounds is undefined, but leaving pointer arithmetic outside of objects undefined would preclude a lot. For example, building an OS page table or DMA, or RDMA, or MMIO, etc...
Non-linear address spaces shouldn't affect pointer arithmetic though, unless I'm misunderstanding something. Otherwise, I guess the implication is that there are systems or implementations that rely on negative pointers; in which case I would think it should be up to the implementation.
This is why I avoid allocating large VLAs, and using them in deep call stacks in general. There's a diminishing return for allocating on the stack beyond a certain point anyway (roughly around a page).
Having a mechanism to abstract this might be nice, but these are things people should hopefully be aware of before using VLAs. std::dynarray has been a bit polarizing though.
One minor thing that should hopefully be considered... a %b/%B conversion for printf et al.
It's useful to print binary representations of things (debugging, conversion, etc...). A number of libc implementations support it as an extension. Forcing people to re-implement it outside of printf is a bit obnoxious considering how simple it is, and that there are already hexadecimal and octal conversions.
Currently, the only compiler I'm aware of that optimizes a bswap correctly is LLVM, which leaves a lot of code in the cold Aside from requiring people to write their own bswap, which is fairly maligned [1] for good reason, It leaves out a reasonably important optimization or potentially requires excess maintenance (platform libs, intrinsics, etc...) for people who do need portable code (the main reason for bswap).
I think languages are starting to take the place of platform independent interfaces, and my personal opinion is that bswap is fairly low hanging fruit. Given that one of the stated goals of C is portability, I think it fits well within the mandate.
[1] http://commandcenter.blogspot.com/2012/04/byte-order-fallacy...