Re: Warnings in objectaddress.c

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Дмитрий Воронин <carriingfate92(at)yandex(dot)ru>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Warnings in objectaddress.c
Date: 2017-10-04 01:29:21
Message-ID: CA+TgmoYXhgu2em8ZaOrqo5W0jHEyRVNx3571d9kD0MVY3Xw2gA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 1, 2017 at 10:33 AM, Дмитрий Воронин
<carriingfate92(at)yandex(dot)ru> wrote:
> I'm building PostgreSQL 10 rc1 sources on Debian wheezy (gcc 4.7). I have those warnings:
>
> objectaddress.c: In function ‘get_object_address’:
> objectaddress.c:1646:10: warning: ‘typeoids[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> objectaddress.c:1578:8: note: ‘typeoids[1]’ was declared here
> objectaddress.c:1623:7: warning: ‘typenames[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> objectaddress.c:1577:14: note: ‘typenames[1]’ was declared here
> objectaddress.c:1646:10: warning: ‘typeoids[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> objectaddress.c:1578:8: note: ‘typeoids[0]’ was declared here
> objectaddress.c:1623:7: warning: ‘typenames[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> objectaddress.c:1577:14: note: ‘typenames[0]’ was declared here
>
> Those variables typeoids and typenames are arrays and are not initialized during definition.
>
> Hope this helps. Thank you!

In theory I think this isn't a problem because List *object should
always be a two-element list whose second element is itself a list of
at least 2 elements, but in practice this doesn't seem like very good
code, because if by chance that list isn't of the proper format, we'll
either crash (if the toplevel list is too short) or do syscache
lookups using undefined values (if the sub-list is too short). The
latter possibility is, I believe, what prompts these warnings. Perhaps
we should apply some glorified version of this:

diff --git a/src/backend/catalog/objectaddress.c
b/src/backend/catalog/objectaddress.c
index c2ad7c675e..9c27ab9434 100644
--- a/src/backend/catalog/objectaddress.c
+++ b/src/backend/catalog/objectaddress.c
@@ -1579,6 +1579,9 @@ get_object_address_opf_member(ObjectType objtype,
int membernum;
int i;

+ if (list_length(object) < 2)
+ elog(ERROR, "fail");
+
/*
* The last element of the object list contains the strategy or procedure
* number. We need to strip that out before getting the opclass/family
@@ -1603,6 +1606,9 @@ get_object_address_opf_member(ObjectType objtype,
break;
}

+ if (i < 2)
+ elog(ERROR, "somebody screwed up");
+
switch (objtype)
{
case OBJECT_AMOP:

However, I'm not 100% sure that would be sufficient to suppress these
warnings, because the compiler has got to be smart enough to know that
elog() doesn't return and that i >= 2 is sufficient to guarantee that
everything is initialized.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-10-04 01:29:22 Re: [HACKERS] BUG #14825: enum type: unsafe use?
Previous Message Wood, Dan 2017-10-04 01:25:12 Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple