Re: GCC 8 warnings

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Devrim Gündüz <devrim(at)gunduz(dot)org>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GCC 8 warnings
Date: 2018-04-28 16:41:35
Message-ID: 20180428164135.quvok5e2775qfzjc@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-04-28 12:16:39 -0400, Tom Lane wrote:
> -SharedFilePath(char *path, SharedFileSet *fileset, const char *name)
> +SharedFilePath(char *path, size_t size, SharedFileSet *fileset, const char *name)
> {
> - char dirpath[MAXPGPATH];
> + char dirpath[MAXPGPATH + 100];
>
> - SharedFileSetPath(dirpath, fileset, ChooseTablespace(fileset, name));
> - snprintf(path, MAXPGPATH, "%s/%s", dirpath, name);
> + SharedFileSetPath(dirpath, sizeof(dirpath), fileset, ChooseTablespace(fileset, name));
> + snprintf(path, size, "%s/%s", dirpath, name);
> }
>
> we basically haven't got any coherent strategy at all, other than
> "whack it till GCC 8 stops complaining". Some of these strings
> might be longer than MAXPGPATH, and we're not very clear on which.
> Worse, the recursive rule that paths are shorter than MAXPGPATH has
> collapsed entirely, so that any reasoning on the assumption that the
> input strings are shorter than MAXPGPATH is now suspect as can be.

> So basically, I think that any argument that these changes make us
> more secure against unwanted path truncation is just horsepucky.
> There's no longer any clear understanding of the maximum supported
> string length, and without global analysis of that you can't say
> that truncation will never happen.

+1

> Perhaps there's an argument for trying to get rid of MAXPGPATH
> altogether, replacing *all* of these fixed-length buffers with
> psprintf-type coding. I kinda doubt it's worth the trouble,
> but if somebody wants to work on it I wouldn't say no.

Same.

> In the meantime, I think our response to GCC 8 should just be to
> enable -Wno-format-truncation. Certainly so in the back branches.
> There isn't one of these changes that is actually fixing a bug,
> which to me says that that warning is unhelpful.

Agreed. Or at least turn down its aggressiveness to the cases where it's
actually sure truncation happens.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-28 16:44:46 Re: inconsistency and inefficiency in setup_conversion()
Previous Message Andres Freund 2018-04-28 16:32:04 Re: Postgres, fsync, and OSs (specifically linux)