Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> I don't get a warning on this with either of these compilers,
>> either with or without asserts enabled:
>
> Perhaps you built with -O0? At least in older versions of gcc, you need
> at least -O1 to get uninitialized-variable warnings. (I've heard some
> claims that the latest versions of gcc don't require that anymore.)
> I don't recommend -O0 as your default optimization level, precisely
> because of this.
This is with default configure and compile options, which results
in this:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g
-I../../../../src/include-D_GNU_SOURCE -I/usr/include/libxml2 -c -o rowtypes.o rowtypes.c -MMD -MP -MF
.deps/rowtypes.Po
> if (GET_4_BYTES(values1[i1]) !=
> GET_4_BYTES(values2[i2]))
> {
> cmpresult = (GET_4_BYTES(values1[i1]) <
> GET_4_BYTES(values2[i2])) ? -1 : 1;
> }
>
> if the two values are in fact equal then this falls through leaving
> cmpresult uninitialized, rather than setting it to zero as it should be;
> which is the case my patch was meant to correct.
I see it now. It is pretty disturbing that the compilers in my
Linux distro don't recognize that as leaving the value
uninitialized.
> This perhaps escaped testing because we aren't using
> record_image_cmp in a way that exposes false nonequality results.
... or the usage pattern happens to leave zero on that location in
the stack when it has mattered.
> I'm not particularly excited about the possibility that attlen might
> not be either 1,2,4, or 8; I'm pretty sure there are lots of other
> places that would go belly-up with such a problem. However, if that
> bothers you the fix is to replace the Assert with an elog(ERROR),
> not to remove the initialization.
Well, I was suggesting replacing the Assert with elog(ERROR); but I
was changing the variable declaration back to uninitialized in what
I was asking people to try so I could find out whether that was the
path causing the uninitialized variable report, to make sure I
understood the report. Nobody who was seeing the warning had
passed along enough information to make that clear.
Now that I understand the problem, I'm fine with the state of
things as currently committed.
Thanks for following up.
-Kevin