Re: snprintf.c hammering memset()
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>,
Mateusz Guzik <mjguzik@gmail.com>
Date: 2018-10-02T00:46:39Z
Lists: 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
Commits
-
Set snprintf.c's maximum number of NL arguments to be 31.
- dee848810d8a 9.5.15 landed
- d5895717e000 9.6.11 landed
- a5b46fc66dfb 9.4.20 landed
- a051c19c3cf4 11.0 landed
- 6483381a4d0b 10.6 landed
- 625b38ea0e98 12.0 landed
- 4ed6dc7d4b33 9.3.25 landed