Horton

Thread

Commits

  1. Remove use of [U]INT64_FORMAT in some translatable strings

  2. Don't use INT64_FORMAT inside message strings

  1. INT64_FORMAT in translatable strings

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2021-04-21T11:00:00Z

    Hello.

I found the following lines in xlogprefetch.c.

>    ereport(LOG,
>            (errmsg("recovery finished prefetching at %X/%X; "
>                    "prefetch = " UINT64_FORMAT ", "
>                    "skip_hit = " UINT64_FORMAT ", "
...

It is found in ja.po as

"recovery finished prefetching at %X/%X; prefetch = "

. . . .

Anyway we can rely on %lld/%llu and we decided to use them in
translatable strings.  So the attached fixes (AFAICS) all instances of
the macros in translatable strings.

# I just found 3286065651 did one instance of that so I excluded that
# from this patch.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  2. Re: INT64_FORMAT in translatable strings

    Michael Paquier <michael@paquier.xyz> — 2021-04-22T10:49:23Z

    On Wed, Apr 21, 2021 at 08:00:00PM +0900, Kyotaro Horiguchi wrote:
> Anyway we can rely on %lld/%llu and we decided to use them in
> translatable strings.  So the attached fixes (AFAICS) all instances of
> the macros in translatable strings.

Indeed, good catch.  Thanks.

> # I just found 3286065651 did one instance of that so I excluded that
> # from this patch.

May I ask why you are using "unsigned long long int" rather uint64?
What you are proposing is more consistent with what's done in the
signed case like 3286065, so no objections from me, but I was just
wondering.  Personally, I think that I would just use "unsigned long
long", like in xlogreader.c or pg_controldata.c to take two examples.
--
Michael

  3. Re: INT64_FORMAT in translatable strings

    Julien Rouhaud <rjuju123@gmail.com> — 2021-04-22T10:56:28Z

    On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
> 
> May I ask why you are using "unsigned long long int" rather uint64?

My understanding is that it's the project standard.  See e.g.
https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us

  4. Re: INT64_FORMAT in translatable strings

    Michael Paquier <michael@paquier.xyz> — 2021-04-22T11:12:25Z

    On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> My understanding is that it's the project standard.  See e.g.
> https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us

FWIW, I am not questioning the format of the specifiers, which is
something I heard about, but the casts used on the values passed down
:)
--
Michael

  5. Re: INT64_FORMAT in translatable strings

    Julien Rouhaud <rjuju123@gmail.com> — 2021-04-22T11:16:04Z

    On Thu, Apr 22, 2021 at 08:12:25PM +0900, Michael Paquier wrote:
> On Thu, Apr 22, 2021 at 06:56:28PM +0800, Julien Rouhaud wrote:
> > My understanding is that it's the project standard.  See e.g.
> > https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us
> 
> FWIW, I am not questioning the format of the specifiers, which is
> something I heard about, but the casts used on the values passed down
> :)

Because uint64 can be unsigned long int or unsigned long long int depending on
the platform?

  6. Re: INT64_FORMAT in translatable strings

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-04-22T13:29:46Z

    Julien Rouhaud <rjuju123@gmail.com> writes:
> On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
>> May I ask why you are using "unsigned long long int" rather uint64?

> My understanding is that it's the project standard.  See e.g.
> https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us

Indeed, using %lld, %llu, etc with a matching cast to "long long" or
"unsigned long long" is the approved way.  Don't use [u]int64 because
that does not necessarily match these format specs.  It's probably
physically compatible, but that won't stop pickier compilers from
nagging about a format mismatch.

But what I thought Michael was griping about is the use of "int",
which is a noise word here.  Either "long long int" or "long long"
will work, but I think we've preferred the latter because shorter.

			regards, tom lane

  7. Re: INT64_FORMAT in translatable strings

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2021-04-23T00:43:09Z

    At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Julien Rouhaud <rjuju123@gmail.com> writes:
> > On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote:
> >> May I ask why you are using "unsigned long long int" rather uint64?
> 
> > My understanding is that it's the project standard.  See e.g.
> > https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us
> 
> Indeed, using %lld, %llu, etc with a matching cast to "long long" or
> "unsigned long long" is the approved way.  Don't use [u]int64 because
> that does not necessarily match these format specs.  It's probably
> physically compatible, but that won't stop pickier compilers from
> nagging about a format mismatch.
> 
> But what I thought Michael was griping about is the use of "int",
> which is a noise word here.  Either "long long int" or "long long"
> will work, but I think we've preferred the latter because shorter.

Yeah, there's no reason for the "int" other than just following the
immediate preceding commit 3286065651. I also prefer the shorter
notations. Attached.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  8. Re: INT64_FORMAT in translatable strings

    Michael Paquier <michael@paquier.xyz> — 2021-04-23T04:26:09Z

    On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
>> But what I thought Michael was griping about is the use of "int",
>> which is a noise word here.  Either "long long int" or "long long"
>> will work, but I think we've preferred the latter because shorter.

Yep, that's what I meant.  Sorry for the confusion.

> Yeah, there's no reason for the "int" other than just following the
> immediate preceding commit 3286065651. I also prefer the shorter
> notations. Attached.

Note that 3286065 only worked on signed integers.

> -					(uint32) (prefetcher->reader->EndRecPtr << 32),
> -					(uint32) (prefetcher->reader->EndRecPtr),
> [..]
> +					LSN_FORMAT_ARGS(prefetcher->reader->EndRecPtr),

Good catch here.  LSN_FORMAT_ARGS() exists to prevent such errors.

And applied.  Thanks!
--
Michael

  9. Re: INT64_FORMAT in translatable strings

    Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2021-04-23T05:11:36Z

    At Fri, 23 Apr 2021 13:26:09 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Fri, Apr 23, 2021 at 09:43:09AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> >> But what I thought Michael was griping about is the use of "int",
> >> which is a noise word here.  Either "long long int" or "long long"
> >> will work, but I think we've preferred the latter because shorter.
> 
> Yep, that's what I meant.  Sorry for the confusion.
> 
> > Yeah, there's no reason for the "int" other than just following the
> > immediate preceding commit 3286065651. I also prefer the shorter
> > notations. Attached.
> 
> Note that 3286065 only worked on signed integers.

Yes. it uses redundant "int" for "long".

> > -					(uint32) (prefetcher->reader->EndRecPtr << 32),
> > -					(uint32) (prefetcher->reader->EndRecPtr),
> > [..]
> > +					LSN_FORMAT_ARGS(prefetcher->reader->EndRecPtr),
> 
> Good catch here.  LSN_FORMAT_ARGS() exists to prevent such errors.
> 
> And applied.  Thanks!

Thanks!

-- 
Kyotaro Horiguchi
NTT Open Source Software Center