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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Optional message to user when terminating/cancellingbackend
Следующее
От: Andres Freund
Дата:
Сообщение: Re: snprintf.c hammering memset()