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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers