On 2013-10-17 12:33:45 -0400, Noah Misch wrote:
> > But if we're bent on minimizing the use of 64-bit arithmetic on 32-bit
> > systems, then presumably I should instead go back and retrofit that
> > patch to use Size rather than uint64 to represent the size of a
> > segment. But then I have two concerns:
>
> I'm not bent on _minimizing_ use of 64-bit arithmetic on 32-bit systems, but I
> disfavor an addition of such usage rippling through various hot paths of the
> system indiscriminately. Making a design choice to use *ALIGN64 in a
> particular module doesn't bother me that way.
I am fine with that as well. It seems unlikely that parallel sort or
whatever will be as hot as tuple deforming code on systems where 32bit
arithmetic is slow.
> > 1. Is there any guarantee that sizeof(intptr_t) >= sizeof(size_t)?
> > (Note that Size is just a typedef for size_t, in c.h)
>
> C99 doesn't require it, but I have never heard of a platform where it is
> false. sizeof(intptr_t) > sizeof(size_t) systems have existed.
Either way, both have to be at least 4byte on 32bit platforms and 8byte
on 64bit ones. So I as well think we're good.
> > 2. If intptr_t is a signed type, as it appears to be, and size_t is an
> > unsigned type, as I believe it to be, then is it safe to use the
> > macros written for the signed type with a value of the unsigned type?
> > Off-hand I can't see a problem there, but I'm not certain I'm not
> > missing something.
>
> Yes; we do that all the time, e.g. the MAXALIGN call in AllocSetAlloc().
> Looping back to my question above, I think it doesn't matter (on a two's
> complement system) whether the macro uses a signed type or an unsigned type.
> It changes the type of the result; that's all. Nonetheless, we should be
> consistent about signedness between the regular and 64-bit macro variants.
I am not all that comfortable on relying on 2s complement here. Maybe we
want to compile without -fwrapv one day which would make signed overflow
undefined again. I don't think there are too many situations where the
compiler would have the required knowledge to optimize stuff away,
but...
So I vote for only using unsigned arithmetic. I don't see anything
preventing that?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
