Re: pgsql: Fix pg_size_bytes() to be more portable.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix pg_size_bytes() to be more portable. |
Дата | |
Msg-id | 10663.1455985971@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix pg_size_bytes() to be more portable. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql: Fix pg_size_bytes() to be more portable.
|
Список | pgsql-committers |
After further thought about the portability implications of this --- 1. We probably gave up support for long-long-less compilers when we agreed to start requiring a working int64 type. On a 32-bit machine that's highly likely to be "long long", and 64-bit machines are mostly new enough that they'd have C99-compliant compilers. 2. Nonetheless, LL is not the same as int64; on modern 64-bit machines it probably means int128. So the right thing to do when writing a constant you mean to be int64 is to use a cast or [U]INT64CONST(). (You need that macro if the constant value might be too wide for plain int, since pickier compilers may reject an unsuffixed constant wider than int.) Your updated code looks fine from here. I looked into changing that code in ecpg, but it would be more invasive than I thought because ecpg doesn't use c.h. Some rearrangement of the ecpg headers would be required, and in view of point #1, it's unlikely to be worth it; it might buy a bit of micro-efficiency but not much. regards, tom lane
В списке pgsql-committers по дате отправления: