Re: fixing more format truncation issues

On Wed, Feb 28, 2018 at 11:14:23PM -0500, Peter Eisentraut wrote:
> AFAICT, the issues addressed here either can't really happen without
> trying very hard, or would cause harmless output truncation.  Still, it
> seems good to clean this up properly and not rely on made-up buffer size
> guesses that turn out to be wrong, even if we don't want to adopt the
> warning options by default.

Good idea.

> One issue that is of external interest is that I increase BGW_MAXLEN
> from 64 to 96.  Apparently, the old value would cause the bgw_name of
> logical replication workers to be truncated in some circumstances.  I
> have also seen truncated background worker names with third-party
> packages, so giving some more room here would be useful.

OK, no complains about that.

@@ -89,7 +89,7 @@ static Datum
 build_pgstattuple_type(pgstattuple_type *stat, FunctionCallInfo fcinfo)
 {
 #define NCOLUMNS    9
-#define NCHARS        32
+#define NCHARS        314

So this one is caused by the output of %.2f...

Enabling them by default would generate some useless noise if the patch
is let as-is as a couple of them are not addressed.  Please see the full
report attached.  Is that intentional?  I am using GCC 7.3 here.

interval.c: In function ‘AppendSeconds’:
interval.c:759:22: warning: ‘%0*d’ directive output between 1 and
2147483648 bytes may exceed minimum required size of 4095
[-Wformat-overflow=]
    sprintf(cp, "%02d.%0*d", abs(sec), precision, (int) Abs(fsec));

pg_rusage.c:64:5: note: in expansion of macro ‘_’
     _("CPU: user: %d.%02d s, system: %d.%02d s, elapsed: %d.%02d s"),
          ^
pg_rusage.c:63:2: note: ‘snprintf’ output between 51 and 108
     bytes into a destination of size 100
       snprintf(result, sizeof(result),
--
Michael