From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yan Haibo <haibo(dot)yan(at)hotmail(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: 回复: Fix potential overflow risks from wcscpy and sprintf |
Date: | 2025-06-16 18:28:06 |
Message-ID: | 650536.1750098486@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yan Haibo <haibo(dot)yan(at)hotmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Devulapalli, Raghuveer | 2025-06-16 18:31:11 | RE: Improve CRC32C performance on SSE4.2 |
Previous Message | Yan Haibo | 2025-06-16 18:04:09 | 回复: Fix potential overflow risks from wcscpy and sprintf |