Kris Jurka <books@ejurka.com> writes:
> char * vs unsigned char * are a good number of them, but I also see:
> "path.c", line 35: warning: storage class after type is obsolescent
Okay, that's easily fixed.
> UINT64CONST produces these in a number of places:
> "xlog.c", line 552: warning: constant promoted to unsigned long long
This is pretty annoying, considering that the entire point of the
UINT64CONST macro is to suppress such complaints. Can you suggest an
incantation that will shut this compiler up?
> "dynloader.c", line 4: warning: empty translation unit
Yup, so it is.
> "pg_shmem.c", line 415: warning: argument #1 is incompatible with
> prototype:
Fixed.
> I see this in both cc and gcc builds:
> cc -Xa -O -v -g -I../../../src/interfaces/libpq -I../../../src/include
> -I/usr/local/include -DFRONTEND -c -o psqlscan.o psqlscan.c
> "../../../src/include/pg_config.h", line 656: warning: macro redefined:
> _FILE_OFFSET_BITS
Hmmm ... that happens only in psqlscan.c? My first guess about the
reason would apply to all our flex-generated files ...
> "float.c", line 168: warning: division by 0
Probably can't avoid this, unless you have another way to generate
NaN on that compiler.
> Applications that have a "int main" prototype don't return values
> "main.c", line 322: warning: Function has no return statement : main
Compilers that don't want to special-case "exit()" have no business
making this complaint :-(. We could possibly add return statements
but I'm worried about introducing "unreachable statement" warnings
from compilers with a slightly larger clue quotient.
> Then there are a whole lot of code reachability warnings in these classes
> - statement not reached
> - end-of-loop code not reached
> - loop not entered at top
I think most of these come from flex and/or bison code that we don't
have a lot of control over.
regards, tom lane
