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+Tgmobw1vM_rOc-Op68LwTNZmRxh-V1+vAkWoAZ=3stAXTgXw@mail.gmail.com
Whole thread Raw
In response to Re: Remove pg_strtouint64(), use strtoull() directly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove pg_strtouint64(), use strtoull() directly
List pgsql-hackers
On Mon, Dec 13, 2021 at 9:44 AM Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Shruthi Gowda
Date:
Subject: Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Next
From: John Naylor
Date:
Subject: Re: speed up verifying UTF-8