Back-patching -Wno-format-truncation.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
Hello. (added Tom in Cc:)
If I build the past versions from 9.4 to 9.6 with GCC8, I find it
really annoying to see the build screen filled with massive number of
warnings of format-truncation, stringop-truncation and
format-overflow.
Just applying the commit 416e3e318c as-is silences the first two.
The last one is silenced by applying 5d923eb29b.
The commit message is sayiing that it is back-patched back at least to
9.4, but it seem that the versions from 9.4 to 9.6 haven't got the
patches.
Tom, would you back-patch the two commits to from 9.4 to 9.6?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
If I build the past versions from 9.4 to 9.6 with GCC8, I find it
really annoying to see the build screen filled with massive number of
warnings of format-truncation, stringop-truncation and
format-overflow.
Just applying the commit 416e3e318c as-is silences the first two.
The last one is silenced by applying 5d923eb29b.
The commit message is sayiing that it is back-patched back at least to
9.4, but it seem that the versions from 9.4 to 9.6 haven't got the
patches.
Tom, would you back-patch the two commits to from 9.4 to 9.6?
Uh ... it sure looks to me like they were back-patched as advertised.
Do you not have these back-branch commits?
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_11_BR [e71658523] 2018-06-16 15:34:07 -0400
Branch: REL_10_STABLE Release: REL_10_5 [416e3e318] 2018-06-16 15:34:07 -0400
Branch: REL9_6_STABLE Release: REL9_6_10 [119290be6] 2018-06-16 15:34:07 -0400
Branch: REL9_5_STABLE Release: REL9_5_14 [14b69a532] 2018-06-16 15:34:07 -0400
Branch: REL9_4_STABLE Release: REL9_4_19 [817d605e4] 2018-06-16 15:34:07 -0400
Branch: REL9_3_STABLE Release: REL9_3_24 [ec5547e56] 2018-06-16 15:34:07 -0400
Use -Wno-format-truncation and -Wno-stringop-truncation, if available.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_11_BR [5d923eb29] 2018-06-16 14:45:47 -0400
Branch: REL_10_STABLE Release: REL_10_5 [189332615] 2018-06-16 14:45:47 -0400
Branch: REL9_6_STABLE Release: REL9_6_10 [8870e2978] 2018-06-16 14:45:47 -0400
Branch: REL9_5_STABLE Release: REL9_5_14 [f3be5d3e7] 2018-06-16 14:45:47 -0400
Branch: REL9_4_STABLE Release: REL9_4_19 [fd079dd09] 2018-06-16 14:45:47 -0400
Branch: REL9_3_STABLE Release: REL9_3_24 [3243cbc08] 2018-06-16 14:45:47 -0400
Use snprintf not sprintf in pg_waldump's timestamptz_to_str.
regards, tom lane
At Tue, 03 Mar 2020 18:44:16 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in
Uh ... it sure looks to me like they were back-patched as advertised.
Do you not have these back-branch commits?Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_11_BR [e71658523] 2018-06-16 15:34:07 -0400
Branch: REL_10_STABLE Release: REL_10_5 [416e3e318] 2018-06-16 15:34:07 -0400
Branch: REL9_6_STABLE Release: REL9_6_10 [119290be6] 2018-06-16 15:34:07 -0400
Branch: REL9_5_STABLE Release: REL9_5_14 [14b69a532] 2018-06-16 15:34:07 -0400
Branch: REL9_4_STABLE Release: REL9_4_19 [817d605e4] 2018-06-16 15:34:07 -0400
Branch: REL9_3_STABLE Release: REL9_3_24 [ec5547e56] 2018-06-16 15:34:07 -0400Use -Wno-format-truncation and -Wno-stringop-truncation, if available.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_11_BR [5d923eb29] 2018-06-16 14:45:47 -0400
Branch: REL_10_STABLE Release: REL_10_5 [189332615] 2018-06-16 14:45:47 -0400
Branch: REL9_6_STABLE Release: REL9_6_10 [8870e2978] 2018-06-16 14:45:47 -0400
Branch: REL9_5_STABLE Release: REL9_5_14 [f3be5d3e7] 2018-06-16 14:45:47 -0400
Branch: REL9_4_STABLE Release: REL9_4_19 [fd079dd09] 2018-06-16 14:45:47 -0400
Branch: REL9_3_STABLE Release: REL9_3_24 [3243cbc08] 2018-06-16 14:45:47 -0400Use snprintf not sprintf in pg_waldump's timestamptz_to_str.
Mmm... I should have created my working trees from stale tracking
branches. I confirmed that they are surely there. Sorry for the bogus
report and thanks for the reply.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center