Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64 - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Date
Msg-id 2467.1304019866@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64  (Dave Page <dpage@postgresql.org>)
Responses Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64  (Dave Page <dpage@postgresql.org>)
List pgsql-committers
Dave Page <dpage@postgresql.org> writes:
> On Thu, Apr 28, 2011 at 6:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Dave, can you poke at this?

> I think we may have to award Sun (or whats left of them) the "Bizarre
> compiler bug of the week" award here.

Yeah.  Has anyone filed a report with them?

> It's actually the val++; that's
> causing the assertion, but I'm darned if I can get it to work. I've
> tried spelling out the addition, casting, changing val to an int64*,
> renaming val, and probably a dozen or so things that are broken, all
> with no success.
> Any other ideas?

I was suspicious that it had something to do with the compiler trying to
optimize the size / mult and size % mult subexpressions to get both
results with one division instruction.  Can you check if removing either
of those makes the crash go away?

If it does have something to do with that, my inclination is to fix it
by rewriting the function to depend on shifting rather than division.
I was considering doing that anyway but decided it was pointless
micro-optimization.  However, if it dodges a compiler bug ...

            regards, tom lane

pgsql-committers by date:

Previous
From: Dave Page
Date:
Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Next
From: Dave Page
Date:
Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64