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
-
Silence minor compiler warnings.
- 302612a6c74f 15.0 cited
-
Use InvalidBucket instead of -1 where appropriate
- 6bd3ec62d9d7 15.0 landed
-
Set pg_class.reltuples for partitioned tables
- 0e69f705cc1a 14.0 cited
-
Redefine pg_class.reltuples to be -1 before the first VACUUM or ANALYZE.
- 3d351d916b20 14.0 cited