From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, ranier(dot)vf(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Signed vs. Unsigned (some) |
Date: | 2021-06-16 08:48:20 |
Message-ID: | 21052764-1e9e-7eeb-753f-ab47c3400249@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-06-16 08:49:51 | Re: Different compression methods for FPI |
Previous Message | Kyotaro Horiguchi | 2021-06-16 08:35:58 | Re: detailed error message of pg_waldump |