On Mon, Dec 13, 2021 at 10:46 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > 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, > > Well, mumble. One must remember that when C was designed, there was > a LOT more variability in hardware designs than we see today. They > could not have put a language with fixed ideas about datatype widths > onto, say, PDP-10s (36-bit words) or Crays (60-bit, IIRC). But it > is a darn shame that people weren't more consistent about mapping > the C types onto machines with S/360-like addressing.
Sure. > > and making more changes to the conventions > > now would cause a whole bunch of unnecessary code churn, probably for > > almost everybody using C. > > The error in your thinking is believing that there *is* a convention. > There isn't; see "long". I mean I pretty much pointed out exactly that thing with my mention of UINT64_FORMAT, so I'm not sure why you're making it seem like I didn't know that. > Anyway, my point is that we have created a set of type names that > have the semantics we want, and we should avoid confusing those with > underlying C types that are *not* guaranteed to be the same thing. I agree entirely, but it's still an annoyance when dealing with printf format codes and other operating-system defined types whose width we don't know. Standardization here makes it easier to write good code; different conventions make it harder. I'm guessing that other people have noticed that too, and that's why we're getting stuff like __int128 instead of redefining long long. -- Robert Haas EDB: http://www.enterprisedb.com
