On Wed, Jul 3, 2024 at 1:34 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> On 18/04/2024 23:29, Thomas Munro wrote:
> > On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> >> I'm not sure I understand the problem here. Do you mean that in theory
> >> a platform's PRId64 could be something other than "l" or "ll"?
> >
> > Yes. I don't know why anyone would do that, and the systems I checked
> > all have the obvious definitions, eg "ld", "lld" etc. Perhaps it's an
> > acceptable risk? It certainly gives us a tidier result.
>
> Could we have a configure check or static assertion for that?
Unfortunately, that theory turned out to be wrong. The usual suspect,
Windows, uses something else: "I64" or something like that. We could
teach our snprintf to grok that, but I don't like the idea anymore.
So let's go back to INT64_MODIFIER, with just a small amount of
configure time work to pick the right value. I couldn't figure out
any header-only way to do that.
> Personally, I find "PRId64" pretty unreadable. "INT64_MODIFIER" wasn't
> nice either, though, and following standards is good, so I'm sure I'll
> get used to it.
Yeah, I like standards a lot but we've painted ourselves into a corner here...
New version attached. This time I was brave enough to try to tackle
src/timezone too, which had comments planning to drop a lot of small
differences against the upstream tzcode once all supported branches
required C99. I suppose that should make future maintenance easier,
and C89 disappeared from our window of interest with PostgreSQL 11.
It's a little hard to understand what changed, but to try to show it
better I diff'd master against upstream (after filtering through sed
and pgindent as recommended by README), and then diff'd patched
against upstream, and then ... ehm.. diff'd the two diffs, so that you
can see there are some hunks that go away.
IMHO it's a rather scary choice on tzcode's part to use int_fastN_t,
and hard for us to verify that it works correctly especially when
combined with our changes, but on the other hand I don't really expect
any system that PostgreSQL can run on to have "fast" types that really
differ from the "exact width" types. My understanding is that this is
something of interest to historical supercomputers and
microcontrollers, but I can't find any evidence of general
purpose/commodity systems that we target using different sizes (anyone
know better?).
