Thank you. Tom. I agree that fixing the sprintf usage is not well-timed at the moment, so I’ve removed that change. Regarding the use of wcsncpy with LOCALE_NAME_MAX_LENGTH - 1, it is a precaution in case the input string is not null-terminated. Thanks again, Haibo
________________________________
发件人: Tom Lane <t...@sss.pgh.pa.us>
发送时间: 2025年6月16日 11:28
收件人: Yan Haibo <haibo....@hotmail.com>
抄送: Peter Eisentraut <pe...@eisentraut.org>; pgsql-hackers@lists.postgresql.org
<pgsql-hackers@lists.postgresql.org>
主题: Re: 回复: Fix potential overflow risks from wcscpy and sprintf
Yan Haibo <haibo....@hotmail.com> writes:
> Thank you. Peter. It seems the patch may have been lost during our earlier
> communication, so I¡¯ve reattached it here.
> I hope it comes through correctly this time.
Thanks for the patch.
Using wcsncpy in search_locale_enum() seems fine, assuming it exists
on Windows (note that code is Windows-only, possibly explaining why
we've not seen other static-analysis reports). I doubt there's any
actual bug there, since we're relying on Windows' own
LOCALE_NAME_MAX_LENGTH constant; but I agree the chain of reasoning
is kind of long. (But shouldn't you write LOCALE_NAME_MAX_LENGTH
not LOCALE_NAME_MAX_LENGTH - 1?)
I'm unexcited about the guc.c changes. There is visibly no bug
there. The only reason to change it would be if we were going
to introduce a strict project policy against using sprintf(),
which we're not likely to given that there are hundreds of other
occurrences in our code base. I don't see a reason to think
that these three are more pressing than the others.
regards, tom lane
0001-Mitigate-potential-overflow-risks-from-wcscpy.patch
Description: 0001-Mitigate-potential-overflow-risks-from-wcscpy.patch
