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
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 |