On Mon, Dec 13, 2021 at 9:44 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah, exactly. That seems like a natural evolution: > short -> 2 bytes > int -> 4 bytes > long -> 8 bytes > long long -> 16 bytes > so I'm surprised that vendors haven't done that already instead > of inventing hacks like __int128.
I really am glad they haven't. I think it's super-annoying that we need hacks like UINT64_FORMAT all over the place. I think it was a mistake not to nail down the size that each type is expected to be in the original C standard, and making more changes to the conventions now would cause a whole bunch of unnecessary code churn, probably for almost everybody using C. It's not like people are writing high-level applications in C these days; it's all low-level stuff that is likely to care about the width of a word. It seems much more sensible to standardize on names for words of all lengths in the standard than to do anything else. I don't really care whether the standard chooses int128, int256, int512, etc. or long long long, long long long long, etc. or reallylong, superlong, incrediblylong, etc. but I hope they define new stuff instead of encouraging implementations to redefine what's there already. -- Robert Haas EDB: http://www.enterprisedb.com