On Thu, Oct 17, 2013 at 12:33 PM, Noah Misch <n...@leadboat.com> 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.
OK. Well that'd probably be simpler from my point of view but I'm not 100% sure. If we're going to allow that, then I think we need 64-bit versions of all of the alignment macros. Anyone think that's a bad idea? >> 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. That's good, I think. Because if it weren't true then we'd potentially need three versions of this macro: one for intptr_t, another for size_t, and a third for uint64. >> 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. So, are you proposing using uintptr_t there instead of intptr_t? Or what? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers