Re: -Wformat-signedness

On 2020-10-29 22:37, Thomas Munro wrote:
> There're probably mostly harmless, being mostly error and debug
> messages and the like, and considering that eg OID parsing tolerates
> negative numbers when reading them back in, but for what it's worth:
> GCC complains about many %d vs %u type mixups if you build with
> $SUBJECT.

I had looked into this some time ago.  I have dusted off my patch again. 
The attached version fixes all warnings for me.

The following are the main categories of issues:

1. enums are unsigned by default in gcc, so all those internal error 
messages "unrecognized blah kind: %d" need to be changed to %u.

I have split that into its own patch since it's easily separable.  All 
the remaining issues are in one patch.

2. Various trickery at the boundary of internal counters that are 
unsigned and external functions or views using signed types.  These need 
another look.

3. Various messages print signed values using %x formats, which need to 
be unsigned.  These might also need another look.

4. Issues with constants being signed by default.  For example, things 
like elog(ERROR, "foo is %u but should be %u", somevar, 55) warns 
because of the constant.  Should be changed to something like 55U for 
symmetry, or change the %u to %d.  This also reaches into genbki 
territory with all the OID constants being generated.

5. Some "surprising" but correct C behavior.  For example, unsigned 
short is promoted to int (not unsigned int) in variable arguments, so 
needs a %d format.

6. Finally, a bunch of uses were just plain wrong and should be corrected.

I haven't found anything that is a really serious bug, but I imagine you 
could run into trouble in various ways when you exceed the INT_MAX 
value.  But then again, if you use up INT_MAX WAL timelines, you 
probably have other problems. ;-)