Обсуждение: [PATCH] work_mem calculation possible overflow
I was just looking through a few of the warnings flagged up by PVS Studio.
I found some warnings around some calculations that were doing work_mem * 1024L and comparing that to a double. On windows 64 sizeof(long) is 4 bytes.
Currently work_mem's maximum value is INT_MAX / 1024, so this should not overflow on windows 64 at the moment, but perhaps if work_mem's maximum is raised in the future then it will. In any case the L suffix on 1024 to widen the type here just seems a bit wrong giving that postgresql supports platforms where sizeof(int) and sizeof(long) is the same.
Its very possible that there are more pressing things to fix from the PVS Studio's list, but I thought I'd have a go at doing a bit of weeding and try reducing the list a bit.
Patch attached.
Regards
David Rowley
Вложения
David Rowley <dgrowleyml@gmail.com> writes:
> I was just looking through a few of the warnings flagged up by PVS Studio.
> I found some warnings around some calculations that were doing work_mem *
> 1024L and comparing that to a double. On windows 64 sizeof(long) is 4 bytes.
> Currently work_mem's maximum value is INT_MAX / 1024, so this should not
> overflow on windows 64 at the moment, but perhaps if work_mem's maximum is
> raised in the future then it will. In any case the L suffix on 1024 to
> widen the type here just seems a bit wrong giving that postgresql supports
> platforms where sizeof(int) and sizeof(long) is the same.
This is not a bug. Note the limitation on the allowed range of work_mem
in guc.c; that's designed precisely to ensure that work_mem * 1024L will
not overflow a long. That's perhaps a bit klugy, but if we wanted to
remove that assumption we'd have to touch far more places than what you
have done here, and most of them would require much uglier changes.
regards, tom lane