[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-hackers
Subject:    Re: [HACKERS] [PATCH] work_mem calculation possible overflow
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2013-12-29 1:57:54
Message-ID: 30214.1388282274 () sss ! pgh ! pa ! us
[Download RAW message or body]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]