Re: glibc qsort() vulnerability
| От | Mats Kindahl |
|---|---|
| Тема | Re: glibc qsort() vulnerability |
| Дата | |
| Msg-id | CA+14426fF6Mx0cM1vi47WLi3qtkNvtmr7DAkCpqVk0x41P9z-A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: glibc qsort() vulnerability (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: glibc qsort() vulnerability
|
| Список | pgsql-hackers |
On Fri, Feb 9, 2024 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Fri, Feb 09, 2024 at 08:52:26AM +0100, Mats Kindahl wrote:
>> The types "int" and "size_t" are treated as s32 and u32 respectively since
>> that seems to be the case for most of the code, even if strictly not
>> correct (size_t can be an unsigned long int for some architecture).
> Why is it safe to do this?
We do pretty much assume that "int" is "int32". But I agree that
assuming anything about the width of size_t is bad. I think we need
a separate pg_cmp_size() or pg_cmp_size_t().
Do we want to have something similar for "int" as well? It seems to be quite common and even though it usually is an int32, it does not have to be.
Best wishes,
Mats Kindahl
Mats Kindahl
regards, tom lane
В списке pgsql-hackers по дате отправления: