On Mon, Dec 13, 2021 at 10:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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