Re: snprintf.c hammering memset()
От | Tom Lane |
---|---|
Тема | Re: snprintf.c hammering memset() |
Дата | |
Msg-id | 6152.1538441199@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | snprintf.c hammering memset() (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | 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 по дате отправления: