Re: Signed vs. Unsigned (some)

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, ranier.vf@gmail.com
Cc: pgsql-hackers@postgresql.org
Date: 2021-06-16T08:48:20Z
Lists: pgsql-hackers
On 15.06.21 10:17, Kyotaro Horiguchi wrote:
> The definitions are not ((type) -1) but ((type) 0xFFFFFFFF) so
> actually they might be different if we forget to widen the constant
> when widening the types.  Regarding to the compiler behavior, I think
> we are assuming C99[1] and C99 defines that -1 is converted to
> Uxxx_MAX. (6.3.1.3 Singed and unsigned integers)
> 
> I'm +0.2 on it.  It might be worthwhile as a matter of style.

I think since we have the constants we should use them.

>> pg_rewind is one special case.
>> All cases of XLogSegNo (uint64) initialization are zero, but in pg_rewind
>> was used -1?
>> I did not find it InvalidXLogSegNo!
> 
> I'm not sure whether that is a thinko that the variable is signed or
> that it is intentional to assign the maximum value.  Anyway, actually
> there's no need for initializing the variable at all. So I don't think
> it's worth changing the initial value. If any compiler actually
> complains about the assignment changing it to zero seems reasonable.
> 
>> Not tested.

I think this case needs some analysis and explanation what is going on. 
I agree that the existing code looks a bit fishy, but we shouldn't just 
change it to something else without understanding what is going on.



Commits

  1. Silence minor compiler warnings.

  2. Use InvalidBucket instead of -1 where appropriate

  3. Set pg_class.reltuples for partitioned tables

  4. Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.