Thread: Fix last unitialized memory warning
This patch is really not necessary from a functional point of view. It
is only necessary if we want to silence a compiler warning.
Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`.
After silencing this warning, all I am left with (given my build
configuration) is:
[1667/2280] Compiling C object src/pl/plpgsql/src/plpgsql.so.p/pl_exec.c.o
In file included from ../src/include/access/htup_details.h:22,
from ../src/pl/plpgsql/src/pl_exec.c:21:
In function ‘assign_simple_var’,
inlined from ‘exec_set_found’ at ../src/pl/plpgsql/src/pl_exec.c:8349:2:
../src/include/varatt.h:230:36: warning: array subscript 0 is outside array bounds of ‘char[0]’ [-Warray-bounds=]
230 | (((varattrib_1b_e *) (PTR))->va_tag)
| ^
../src/include/varatt.h:94:12: note: in definition of macro ‘VARTAG_IS_EXPANDED’
94 | (((tag) & ~1) == VARTAG_EXPANDED_RO)
| ^~~
../src/include/varatt.h:284:57: note: in expansion of macro ‘VARTAG_1B_E’
284 | #define VARTAG_EXTERNAL(PTR) VARTAG_1B_E(PTR)
| ^~~~~~~~~~~
../src/include/varatt.h:301:57: note: in expansion of macro ‘VARTAG_EXTERNAL’
301 | (VARATT_IS_EXTERNAL(PTR) && !VARTAG_IS_EXPANDED(VARTAG_EXTERNAL(PTR)))
| ^~~~~~~~~~~~~~~
../src/pl/plpgsql/src/pl_exec.c:8537:17: note: in expansion of macro ‘VARATT_IS_EXTERNAL_NON_EXPANDED’
8537 | VARATT_IS_EXTERNAL_NON_EXPANDED(DatumGetPointer(newvalue)))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From my perspective, this warning definitely seems like a false
positive, but I don't know the code well-enough to say that for certain.
--
Tristan Partin
Neon (https://neon.tech)
Attachment
On Wed, Jun 7, 2023 at 7:31 AM Tristan Partin <tristan@neon.tech> wrote:
>
> This patch is really not necessary from a functional point of view. It
> is only necessary if we want to silence a compiler warning.
>
> Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`.
...
> From my perspective, this warning definitely seems like a false
> positive, but I don't know the code well-enough to say that for certain.
It was a bit confusing to see a patch for src/bin/pgbench/pgbench.c,
but that file not mentioned in the warning messages you quoted. I take
it that your patch silences a warning in pgbench.c; it would've been
nice to see the actual warning.
- PgBenchValue vargs[MAX_FARGS];
+ PgBenchValue vargs[MAX_FARGS] = { 0 };
If I'm right about what kind of warning this might've caused (use of
possibly uninitialized variable), you're correct that it is benign.
The for loop after declarations initializes all the elements of this
array using evaluateExpr(), and if the initialization fails for some
reason, the loop ends prematurely and returns from the function.
I analyzed a few code-paths that return true from evaluateExpr(), and
I'd like to believe that _all_ code paths that return true also
initialize the array element passed. But because there are so many
branches and function calls beneath evaluateExpr(), I think it's
better to be paranoid and initialize all the array elements to 0.
Also, it is better to initialize/clear an array at the point of
definition, like your patch does. So, +1 to the patch.
Best regards,
Gurjeet
http://Gurje.et
On 07.06.23 16:31, Tristan Partin wrote: > This patch is really not necessary from a functional point of view. It > is only necessary if we want to silence a compiler warning. > > Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`. > > After silencing this warning, all I am left with (given my build > configuration) is: > > [1667/2280] Compiling C object src/pl/plpgsql/src/plpgsql.so.p/pl_exec.c.o > In file included from ../src/include/access/htup_details.h:22, > from ../src/pl/plpgsql/src/pl_exec.c:21: > In function ‘assign_simple_var’, > inlined from ‘exec_set_found’ at ../src/pl/plpgsql/src/pl_exec.c:8349:2: > ../src/include/varatt.h:230:36: warning: array subscript 0 is outside array bounds of ‘char[0]’ [-Warray-bounds=] > 230 | (((varattrib_1b_e *) (PTR))->va_tag) > | ^ > ../src/include/varatt.h:94:12: note: in definition of macro ‘VARTAG_IS_EXPANDED’ > 94 | (((tag) & ~1) == VARTAG_EXPANDED_RO) > | ^~~ > ../src/include/varatt.h:284:57: note: in expansion of macro ‘VARTAG_1B_E’ > 284 | #define VARTAG_EXTERNAL(PTR) VARTAG_1B_E(PTR) > | ^~~~~~~~~~~ > ../src/include/varatt.h:301:57: note: in expansion of macro ‘VARTAG_EXTERNAL’ > 301 | (VARATT_IS_EXTERNAL(PTR) && !VARTAG_IS_EXPANDED(VARTAG_EXTERNAL(PTR))) > | ^~~~~~~~~~~~~~~ > ../src/pl/plpgsql/src/pl_exec.c:8537:17: note: in expansion of macro ‘VARATT_IS_EXTERNAL_NON_EXPANDED’ > 8537 | VARATT_IS_EXTERNAL_NON_EXPANDED(DatumGetPointer(newvalue))) > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > From my perspective, this warning definitely seems like a false > positive, but I don't know the code well-enough to say that for certain. I cannot reproduce this warning with gcc-13. Are you using any non-standard optimization options. Could you give your full configure and build commands and the OS?
On Mon Jul 3, 2023 at 1:19 AM CDT, Peter Eisentraut wrote: > On 07.06.23 16:31, Tristan Partin wrote: > > This patch is really not necessary from a functional point of view. It > > is only necessary if we want to silence a compiler warning. > > > > Tested on `gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)`. > > > > After silencing this warning, all I am left with (given my build > > configuration) is: > > > > [1667/2280] Compiling C object src/pl/plpgsql/src/plpgsql.so.p/pl_exec.c.o > > In file included from ../src/include/access/htup_details.h:22, > > from ../src/pl/plpgsql/src/pl_exec.c:21: > > In function ‘assign_simple_var’, > > inlined from ‘exec_set_found’ at ../src/pl/plpgsql/src/pl_exec.c:8349:2: > > ../src/include/varatt.h:230:36: warning: array subscript 0 is outside array bounds of ‘char[0]’ [-Warray-bounds=] > > 230 | (((varattrib_1b_e *) (PTR))->va_tag) > > | ^ > > ../src/include/varatt.h:94:12: note: in definition of macro ‘VARTAG_IS_EXPANDED’ > > 94 | (((tag) & ~1) == VARTAG_EXPANDED_RO) > > | ^~~ > > ../src/include/varatt.h:284:57: note: in expansion of macro ‘VARTAG_1B_E’ > > 284 | #define VARTAG_EXTERNAL(PTR) VARTAG_1B_E(PTR) > > | ^~~~~~~~~~~ > > ../src/include/varatt.h:301:57: note: in expansion of macro ‘VARTAG_EXTERNAL’ > > 301 | (VARATT_IS_EXTERNAL(PTR) && !VARTAG_IS_EXPANDED(VARTAG_EXTERNAL(PTR))) > > | ^~~~~~~~~~~~~~~ > > ../src/pl/plpgsql/src/pl_exec.c:8537:17: note: in expansion of macro ‘VARATT_IS_EXTERNAL_NON_EXPANDED’ > > 8537 | VARATT_IS_EXTERNAL_NON_EXPANDED(DatumGetPointer(newvalue))) > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > From my perspective, this warning definitely seems like a false > > positive, but I don't know the code well-enough to say that for certain. > > I cannot reproduce this warning with gcc-13. Are you using any > non-standard optimization options. Could you give your full configure > and build commands and the OS? Thanks for following up. My system is Fedora 38. I can confirm this is still happening on master. $ gcc --version gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ meson setup build --buildtype=release $ ninja -C build -- Tristan Partin Neon (https://neon.tech)
On 05.07.23 23:06, Tristan Partin wrote: > Thanks for following up. My system is Fedora 38. I can confirm this is > still happening on master. > > $ gcc --version > gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) > Copyright (C) 2023 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > $ meson setup build --buildtype=release This buildtype turns on -O3 warnings. We have usually opted against chasing warnings in -O3 level because there are often some false-positive uninitialized variable warnings with every new compiler. Note that we have set the default build type to debugoptimized, for that reason.
On Thu Jul 6, 2023 at 3:21 AM CDT, Peter Eisentraut wrote: > On 05.07.23 23:06, Tristan Partin wrote: > > Thanks for following up. My system is Fedora 38. I can confirm this is > > still happening on master. > > > > $ gcc --version > > gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) > > Copyright (C) 2023 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > $ meson setup build --buildtype=release > > This buildtype turns on -O3 warnings. We have usually opted against > chasing warnings in -O3 level because there are often some > false-positive uninitialized variable warnings with every new compiler. > > Note that we have set the default build type to debugoptimized, for that > reason. Good to know, thanks. Regarding the original patch, do you think it is good to be applied? -- Tristan Partin Neon (https://neon.tech)
Hi, On 2023-07-06 10:21:44 +0200, Peter Eisentraut wrote: > On 05.07.23 23:06, Tristan Partin wrote: > > Thanks for following up. My system is Fedora 38. I can confirm this is > > still happening on master. > > > > $ gcc --version > > gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) > > Copyright (C) 2023 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > $ meson setup build --buildtype=release > > This buildtype turns on -O3 warnings. We have usually opted against chasing > warnings in -O3 level because there are often some false-positive > uninitialized variable warnings with every new compiler. OTOH, -O3 is substantially faster IME in cpu bound tests than -O2. It doesn't seem wise to me for the project to basically say that that's not advisable due to the level of warnings created. I've also found bugs with -O3 that -O2 didn't find. And often -O3 warnings end up showing up with -O2 a compiler major version or three down the line, so it's often just deferring work. Greetings, Andres Freund
On 06.07.23 15:41, Tristan Partin wrote: > On Thu Jul 6, 2023 at 3:21 AM CDT, Peter Eisentraut wrote: >> On 05.07.23 23:06, Tristan Partin wrote: >>> Thanks for following up. My system is Fedora 38. I can confirm this is >>> still happening on master. >>> >>> $ gcc --version >>> gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) >>> Copyright (C) 2023 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> $ meson setup build --buildtype=release >> >> This buildtype turns on -O3 warnings. We have usually opted against >> chasing warnings in -O3 level because there are often some >> false-positive uninitialized variable warnings with every new compiler. >> >> Note that we have set the default build type to debugoptimized, for that >> reason. > > Good to know, thanks. > > Regarding the original patch, do you think it is good to be applied? That patch looks reasonable. But I can't actually reproduce the warning, even with gcc-13. I do get the warning from plpgsql. Can you show the warning you are seeing?
On Sun Jul 9, 2023 at 2:23 AM CDT, Peter Eisentraut wrote:
> On 06.07.23 15:41, Tristan Partin wrote:
> > On Thu Jul 6, 2023 at 3:21 AM CDT, Peter Eisentraut wrote:
> >> On 05.07.23 23:06, Tristan Partin wrote:
> >>> Thanks for following up. My system is Fedora 38. I can confirm this is
> >>> still happening on master.
> >>>
> >>> $ gcc --version
> >>> gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
> >>> Copyright (C) 2023 Free Software Foundation, Inc.
> >>> This is free software; see the source for copying conditions. There is NO
> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >>> $ meson setup build --buildtype=release
> >>
> >> This buildtype turns on -O3 warnings. We have usually opted against
> >> chasing warnings in -O3 level because there are often some
> >> false-positive uninitialized variable warnings with every new compiler.
> >>
> >> Note that we have set the default build type to debugoptimized, for that
> >> reason.
> >
> > Good to know, thanks.
> >
> > Regarding the original patch, do you think it is good to be applied?
>
> That patch looks reasonable. But I can't actually reproduce the
> warning, even with gcc-13. I do get the warning from plpgsql. Can you
> show the warning you are seeing?
Here is the full warning that the original patch suppresses.
[1360/1876] Compiling C object src/bin/pgbench/pgbench.p/pgbench.c.o
In function ‘coerceToInt’,
inlined from ‘evalStandardFunc’ at ../src/bin/pgbench/pgbench.c:2607:11:
../src/bin/pgbench/pgbench.c:2032:17: warning: ‘vargs[0].type’ may be used uninitialized [-Wmaybe-uninitialized]
2032 | if (pval->type == PGBT_INT)
| ~~~~^~~~~~
../src/bin/pgbench/pgbench.c: In function ‘evalStandardFunc’:
../src/bin/pgbench/pgbench.c:2240:22: note: ‘vargs’ declared here
2240 | PgBenchValue vargs[MAX_FARGS];
| ^~~~~
In function ‘coerceToInt’,
inlined from ‘evalStandardFunc’ at ../src/bin/pgbench/pgbench.c:2607:11:
../src/bin/pgbench/pgbench.c:2034:32: warning: ‘vargs[0].u.ival’ may be used uninitialized [-Wmaybe-uninitialized]
2034 | *ival = pval->u.ival;
| ~~~~~~~^~~~~
../src/bin/pgbench/pgbench.c: In function ‘evalStandardFunc’:
../src/bin/pgbench/pgbench.c:2240:22: note: ‘vargs’ declared here
2240 | PgBenchValue vargs[MAX_FARGS];
| ^~~~~
In function ‘coerceToInt’,
inlined from ‘evalStandardFunc’ at ../src/bin/pgbench/pgbench.c:2607:11:
../src/bin/pgbench/pgbench.c:2039:40: warning: ‘vargs[0].u.dval’ may be used uninitialized [-Wmaybe-uninitialized]
2039 | double dval = rint(pval->u.dval);
| ^~~~~~~~~~~~~~~~~~
../src/bin/pgbench/pgbench.c: In function ‘evalStandardFunc’:
../src/bin/pgbench/pgbench.c:2240:22: note: ‘vargs’ declared here
2240 | PgBenchValue vargs[MAX_FARGS];
| ^~~~~
--
Tristan Partin
Neon (https://neon.tech)
On 19.07.23 19:15, Tristan Partin wrote:
> On Sun Jul 9, 2023 at 2:23 AM CDT, Peter Eisentraut wrote:
>> On 06.07.23 15:41, Tristan Partin wrote:
>> > On Thu Jul 6, 2023 at 3:21 AM CDT, Peter Eisentraut wrote:
>> >> On 05.07.23 23:06, Tristan Partin wrote:
>> >>> Thanks for following up. My system is Fedora 38. I can confirm
>> this is
>> >>> still happening on master.
>> >>>
>> >>> $ gcc --version
>> >>> gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
>> >>> Copyright (C) 2023 Free Software Foundation, Inc.
>> >>> This is free software; see the source for copying conditions.
>> There is NO
>> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>> >>> $ meson setup build --buildtype=release
>> >>
>> >> This buildtype turns on -O3 warnings. We have usually opted against
>> >> chasing warnings in -O3 level because there are often some
>> >> false-positive uninitialized variable warnings with every new
>> compiler.
>> >>
>> >> Note that we have set the default build type to debugoptimized, for
>> that
>> >> reason.
>> > > Good to know, thanks.
>> > > Regarding the original patch, do you think it is good to be applied?
>>
>> That patch looks reasonable. But I can't actually reproduce the
>> warning, even with gcc-13. I do get the warning from plpgsql. Can
>> you show the warning you are seeing?
>
> Here is the full warning that the original patch suppresses.
I was able to reproduce the warning now on Fedora. I agree with the patch
- PgBenchValue vargs[MAX_FARGS];
+ PgBenchValue vargs[MAX_FARGS] = { 0 };
I suggest to also do
typedef enum
{
- PGBT_NO_VALUE,
+ PGBT_NO_VALUE = 0,
to make clear that the initialization value is meant to be invalid.
I also got the plpgsql warning that you showed earlier, but I couldn't
think of a reasonable way to fix that.
On Tue Aug 8, 2023 at 5:20 AM CDT, Peter Eisentraut wrote:
> On 19.07.23 19:15, Tristan Partin wrote:
> > On Sun Jul 9, 2023 at 2:23 AM CDT, Peter Eisentraut wrote:
> >> On 06.07.23 15:41, Tristan Partin wrote:
> >> > On Thu Jul 6, 2023 at 3:21 AM CDT, Peter Eisentraut wrote:
> >> >> On 05.07.23 23:06, Tristan Partin wrote:
> >> >>> Thanks for following up. My system is Fedora 38. I can confirm
> >> this is
> >> >>> still happening on master.
> >> >>>
> >> >>> $ gcc --version
> >> >>> gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
> >> >>> Copyright (C) 2023 Free Software Foundation, Inc.
> >> >>> This is free software; see the source for copying conditions.
> >> There is NO
> >> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> >> PURPOSE.
> >> >>> $ meson setup build --buildtype=release
> >> >>
> >> >> This buildtype turns on -O3 warnings. We have usually opted against
> >> >> chasing warnings in -O3 level because there are often some
> >> >> false-positive uninitialized variable warnings with every new
> >> compiler.
> >> >>
> >> >> Note that we have set the default build type to debugoptimized, for
> >> that
> >> >> reason.
> >> > > Good to know, thanks.
> >> > > Regarding the original patch, do you think it is good to be applied?
> >>
> >> That patch looks reasonable. But I can't actually reproduce the
> >> warning, even with gcc-13. I do get the warning from plpgsql. Can
> >> you show the warning you are seeing?
> >
> > Here is the full warning that the original patch suppresses.
>
> I was able to reproduce the warning now on Fedora. I agree with the patch
>
> - PgBenchValue vargs[MAX_FARGS];
> + PgBenchValue vargs[MAX_FARGS] = { 0 };
>
> I suggest to also do
>
> typedef enum
> {
> - PGBT_NO_VALUE,
> + PGBT_NO_VALUE = 0,
>
> to make clear that the initialization value is meant to be invalid.
>
> I also got the plpgsql warning that you showed earlier, but I couldn't
> think of a reasonable way to fix that.
Applied in v2.
--
Tristan Partin
Neon (https://neon.tech)
Attachment
On 08.08.23 17:14, Tristan Partin wrote:
>> I was able to reproduce the warning now on Fedora. I agree with the
>> patch
>>
>> - PgBenchValue vargs[MAX_FARGS];
>> + PgBenchValue vargs[MAX_FARGS] = { 0 };
>>
>> I suggest to also do
>>
>> typedef enum
>> {
>> - PGBT_NO_VALUE,
>> + PGBT_NO_VALUE = 0,
>>
>> to make clear that the initialization value is meant to be invalid.
>>
>> I also got the plpgsql warning that you showed earlier, but I couldn't
>> think of a reasonable way to fix that.
>
> Applied in v2.
committed
On 09.08.23 10:07, Peter Eisentraut wrote:
> On 08.08.23 17:14, Tristan Partin wrote:
>>> I was able to reproduce the warning now on Fedora. I agree with the
>>> patch
>>>
>>> - PgBenchValue vargs[MAX_FARGS];
>>> + PgBenchValue vargs[MAX_FARGS] = { 0 };
>>>
>>> I suggest to also do
>>>
>>> typedef enum
>>> {
>>> - PGBT_NO_VALUE,
>>> + PGBT_NO_VALUE = 0,
>>>
>>> to make clear that the initialization value is meant to be invalid.
>>>
>>> I also got the plpgsql warning that you showed earlier, but I
>>> couldn't think of a reasonable way to fix that.
>>
>> Applied in v2.
>
> committed
This patch has apparently upset one buildfarm member with a very old
compiler:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD
Any thoughts?
On Wed Aug 9, 2023 at 10:02 AM CDT, Peter Eisentraut wrote:
> On 09.08.23 10:07, Peter Eisentraut wrote:
> > On 08.08.23 17:14, Tristan Partin wrote:
> >>> I was able to reproduce the warning now on Fedora. I agree with the
> >>> patch
> >>>
> >>> - PgBenchValue vargs[MAX_FARGS];
> >>> + PgBenchValue vargs[MAX_FARGS] = { 0 };
> >>>
> >>> I suggest to also do
> >>>
> >>> typedef enum
> >>> {
> >>> - PGBT_NO_VALUE,
> >>> + PGBT_NO_VALUE = 0,
> >>>
> >>> to make clear that the initialization value is meant to be invalid.
> >>>
> >>> I also got the plpgsql warning that you showed earlier, but I
> >>> couldn't think of a reasonable way to fix that.
> >>
> >> Applied in v2.
> >
> > committed
>
> This patch has apparently upset one buildfarm member with a very old
> compiler:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD
>
> Any thoughts?
Best I could find is SO question[0] which links out to[1]. Try this
patch. Otherwise, a memset() would probably do too.
[0]: https://stackoverflow.com/questions/13746033/how-to-repair-warning-missing-braces-around-initializer
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
--
Tristan Partin
Neon (https://neon.tech)
Attachment
On Wed, Aug 09, 2023 at 10:29:56AM -0500, Tristan Partin wrote: > On Wed Aug 9, 2023 at 10:02 AM CDT, Peter Eisentraut wrote: > > > > This patch has apparently upset one buildfarm member with a very old > > compiler: > > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD > > > > Any thoughts? > > Best I could find is SO question[0] which links out to[1]. Try this patch. > Otherwise, a memset() would probably do too. Yes, it's a buggy warning that came up in the past a few times as I recall, for which we previously used the {{...}} approach to silence it. As there have been previous complaints about it, I removed the -Werror from lapwing and forced a new run to make it green again.
On Thu, Aug 10, 2023 at 8:57 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Wed, Aug 09, 2023 at 10:29:56AM -0500, Tristan Partin wrote:
> On Wed Aug 9, 2023 at 10:02 AM CDT, Peter Eisentraut wrote:
> >
> > This patch has apparently upset one buildfarm member with a very old
> > compiler:
> > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD
> >
> > Any thoughts?
>
> Best I could find is SO question[0] which links out to[1]. Try this patch.
> Otherwise, a memset() would probably do too.
Yes, it's a buggy warning that came up in the past a few times as I recall, for
which we previously used the {{...}} approach to silence it.
I came across this warning too on one of my VMs, with gcc 4.8.5. +1 to
silence it with {{...}}. We did that in d937904 and 6392f2a (and maybe
more).
In case it helps, here is the GCC I'm on.
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Thanks
Richard
silence it with {{...}}. We did that in d937904 and 6392f2a (and maybe
more).
In case it helps, here is the GCC I'm on.
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)
Thanks
Richard
On 09.08.23 17:29, Tristan Partin wrote:
> On Wed Aug 9, 2023 at 10:02 AM CDT, Peter Eisentraut wrote:
>> On 09.08.23 10:07, Peter Eisentraut wrote:
>> > On 08.08.23 17:14, Tristan Partin wrote:
>> >>> I was able to reproduce the warning now on Fedora. I agree with
>> the >>> patch
>> >>>
>> >>> - PgBenchValue vargs[MAX_FARGS];
>> >>> + PgBenchValue vargs[MAX_FARGS] = { 0 };
>> >>>
>> >>> I suggest to also do
>> >>>
>> >>> typedef enum
>> >>> {
>> >>> - PGBT_NO_VALUE,
>> >>> + PGBT_NO_VALUE = 0,
>> >>>
>> >>> to make clear that the initialization value is meant to be invalid.
>> >>>
>> >>> I also got the plpgsql warning that you showed earlier, but I >>>
>> couldn't think of a reasonable way to fix that.
>> >>
>> >> Applied in v2.
>> > > committed
>>
>> This patch has apparently upset one buildfarm member with a very old
>> compiler:
>> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=lapwing&br=HEAD
>>
>> Any thoughts?
>
> Best I could find is SO question[0] which links out to[1]. Try this
> patch.
committed this fix