Re: Remove pg_strtouint64(), use strtoull() directly - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Remove pg_strtouint64(), use strtoull() directly
Date
Msg-id CA+TgmoYLeSVULGR66v5GPWc0YrVDwRevAH4XTEhg_tc5r28nxQ@mail.gmail.com
Whole thread Raw
In response to Re: Remove pg_strtouint64(), use strtoull() directly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: [PATCH]Comment improvement in publication.sql
Next
From: John Naylor
Date:
Subject: speed up text_position() for utf-8