On Mon, Apr 29, 2019 at 8:11 AM Andres Freund <andres@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. A few uses of "long" seem to be real live bugs,
albeit bugs that are very unlikely to ever hit.
_h_indexbuild() has the same bug as _bt_load(), also due to commit
ab0dfc961b6 -- I spotted that in passing when I used grep.
> We read from larger files in a few places though. E.g. pg_dump. Most
> places really just should use pgoff_t...
I wasn't even aware of pgoff_t. It is only used in frontend utilities
that I don't know that much about, whereas off_t is used all over the
backend code.
--
Peter Geoghegan