Re: pgsql: Fix pg_size_bytes() to be more portable.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix pg_size_bytes() to be more portable.
Date: 2016-02-20 16:32:51
Message-ID: 10663.1455985971@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Dean Rasheed 2016-02-20 17:24:41 Re: pgsql: Fix pg_size_bytes() to be more portable.
Previous Message Joe Conway 2016-02-20 16:31:09 Re: pgsql: Add pg_size_bytes() to parse human-readable size strings.