On 29.10.24 07:51, Michael Paquier wrote:
On Tue, Oct 29, 2024 at 07:38:36AM +0100, Peter Eisentraut wrote:
I think it could be useful to set up some better test coverage for various
things overflowing signed integer maximums. For example, maybe you could
hack initdb to advance the OID counter
that want some clean code:) But FWIW, "-Wformat-signedness"
is not supported by clang so far, so if people is using clang, they
still can't benefit from this changes.
clang 19 supports it now.
My soluation (I use clang
everyday) is adding a "gcc-checker" for my c file,
On Tue, Oct 29, 2024 at 07:38:36AM +0100, Peter Eisentraut wrote:
> I think it could be useful to set up some better test coverage for various
> things overflowing signed integer maximums. For example, maybe you could
> hack initdb to advance the OID counter to INT32_MAX+1 or thereabouts and run
>
or 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.
When Dean pointed me this thread[1], I was thinking
On Tue, Nov 10, 2020 at 4:25 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > 1. enums are unsigned by default in gcc, so all those internal error
> > messages "unrecognized blah kind: %d" need to be changed to %u.
>
> Do we have reason to think that that is true in every C compiler?
> My own pr
Peter Eisentraut writes:
> 1. enums are unsigned by default in gcc, so all those internal error
> messages "unrecognized blah kind: %d" need to be changed to %u.
Do we have reason to think that that is true in every C compiler?
My own preference for this would be to leave the messages as-is
and
Hi hackers,
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.
