Re: snprintf.c hammering memset() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: snprintf.c hammering memset()
Date
Msg-id 6152.1538441199@sss.pgh.pa.us
Whole thread Raw
In response to snprintf.c hammering memset()  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> PrintfArgType is an enum, and we define NL_ARGMAX as 16 if the OS
> didn't already define it.  On FreeBSD 11, NL_ARGMAX was defined as 99
> in <limits.h>.  On FreeBSD 12, it is defined as 65536... ouch.  On a
> Debian box I see it is 4096.

Some further research:

* My Red Hat boxes also think it's 4096.

* macOS thinks it's just 9.

* Assuming I've grepped the .po files correctly, we have no translatable
messages today that use more than 9 %'s.  That's not a totally accurate
result because I didn't try to count "*" precision/width specs, which'd
also count against ARGMAX.  Still, we couldn't be needing much more than
9 slots.

* It's completely silly to imagine that anybody would write a printf call
with more than, perhaps, a couple dozen arguments.  So these OS values
must be getting set with an eye to some other use-case for NL_ARGMAX
besides printf field order control.

Setting snprintf's limit to 16 might be a bit tight based on the observed
results for translatable messages, but I'd be entirely comfortable with
32.  The values we're getting from the OS are just silly.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Optional message to user when terminating/cancellingbackend
Next
From: Andres Freund
Date:
Subject: Re: snprintf.c hammering memset()