Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.
Date: 2016-02-21 18:48:42
Message-ID: 13545.1456080522@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Joe Conway (mail(at)joeconway(dot)com) wrote:
>> FWIW, strcpy() was being used in src/bin/pg_config/pg_config.c that I
>> started with -- does that mean we are not getting Coverity coverage of
>> src/bin?

> Coverity does run against src/bin also. It's possible this was
> identified as an issue in pg_config.c, but, as Tom notes, it may not be
> an actual bug and might have been marked as a non-bug in Coverity.

It looks to me like the previous coding was

static char mypath[MAXPGPATH];
...
char path[MAXPGPATH];
...
strcpy(path, mypath);

so Coverity probably didn't complain because it could see that the source
was also a buffer of size MAXPGPATH. With the new arrangement it was
probably using an assumption that get_configdata() could be called with
any length of string.

I am not sure how much cross-file analysis Coverity does --- it seems to
do some, but in other cases it acts like it doesn't know anything about
the call sites. It's possible that it did know that the existing callers
all use MAXPGPATH-sized buffers, but whined anyway on the not-unreasonable
grounds that global functions should be prepared for new callers.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-02-21 20:23:22 pgsql: Docs: make prose discussion match the ordering of Table 9-58.
Previous Message Stephen Frost 2016-02-21 18:37:18 Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2016-02-21 18:56:30 Re: Re: Add generate_series(date, date) and generate_series(date, date, integer)
Previous Message Stephen Frost 2016-02-21 18:37:18 Re: [COMMITTERS] pgsql: Cosmetic improvements in new config_info code.