Peter Geoghegan <p...@bowt.ie> writes:
> On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <and...@anarazel.de> wrote:
>> I think we should start by just removing all uses of long. There's
>> really no excuse for them today, and a lot of them are bugs waiting to
>> happen.
> I like the idea of banning "long" altogether. It will probably be hard
> to keep it out of third party code that we vendor-in, or even code
> that interfaces with libraries in some way, but it should be removed
> from everything else. It actually doesn't seem particularly hard to do
> so, based on a quick grep of src/backend/. Most uses of "long" is code
> that sizes something in local memory, where "long" works for the same
> reason as it works when calculating the size of a work_mem allocation
> -- ugly, but correct.
There's more to that than you might realize. For example, guc.c
enforces a limit on work_mem that's designed to ensure that
expressions like "work_mem * 1024L" won't overflow, and there are
similar choices elsewhere. I'm not sure if we want to go to the
effort of rethinking that; it's not really a bug, though it does
result in 64-bit Windows being more restricted than it has to be.
Trying to get rid of type-L constants along with more explicit
uses of "long" would be a PITA I'm afraid.
Another problem is that while "%lu" format specifiers are portable,
INT64_FORMAT is a *big* pain, not least because you can't put it into
translatable strings without causing problems. To the extent that
we could go over to "%zu" instead, maybe this could be finessed,
but blind "s/long/int64/g" isn't going to be any fun.
regards, tom lane
