Re: Warning in the RecordTransactionAbort routine during compilation with O3 flag

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Warning in the RecordTransactionAbort routine during compilation with O3 flag
Date: 2019-12-09 08:03:16
Message-ID: 20191209080316.GA72921@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 09, 2019 at 08:49:26AM +0500, Andrey Lepikhov wrote:
> xact.c: In function ‘RecordTransactionAbort’:
> xact.c:5709:55: warning: argument 1 null where non-null expected [-Wnonnull]
> XLogRegisterData(unconstify(char *, twophase_gid), strlen(twophase_gid)
> + 1);

Assert(twophase_gid != NULL);
-
- if (XLogLogicalInfoActive())
- xl_xinfo.xinfo |= XACT_XINFO_HAS_GID;

xlinfo is set in the first part logging the transaction commit and the
record data is registered in the second, so I think that the original
coding makes more sense than what you are suggesting. Perhaps it
would help to just add an assertion on twophase_gid to make sure that
it is not NULL in the part registering the data? After that we really
have no bugs here, so it does not really help much..

> formatting.c: In function ‘parse_datetime’:
> formatting.c:4229:13: warning: ‘flags’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
> if (flags & DCH_ZONED)

- uint32 flags;
+ uint32 flags = 0;

do_to_timestamp(date_txt, fmt, strict, &tm, &fsec, &fprec, &flags, have_error);

For this one, OK. Wouldn't it be better to initialize flags, fprec
and have_error directly in do_to_timestamp if they are not NULL? This
way future callers of the routine, if any, won't miss the
initialization.

By the way, are you using more specific CFLAGS to see that? With -O3
and -Wnonnull I cannot spot both issues with GCC 9.2.1.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-12-09 08:06:30 Re: REINDEX CONCURRENTLY unexpectedly fails
Previous Message Michael Paquier 2019-12-09 07:28:56 Re: Unexpected extra row from jsonb_path_query() with a recursive path