Fix last unitialized memory warning

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)

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&amp;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&amp;br=HEAD

Any thoughts?

Best I could find is SO question[0]https://stackoverflow.com/questions/13746033/how-to-repair-warning-missing-braces-around-initializer which links out to[1]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119. 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)

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&amp;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&amp;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

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&amp;br=HEAD

Any thoughts?

Best I could find is SO question[0] which links out to[1]. Try this
patch.

committed this fix