Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> some more(I have removed duplicates and ones that should be fixed by
> your latest commits though):
I did what I could with this batch. Some comments:
> animal: salamander warnings: 27
> cash.c: In function `cash_in':
> cash.c:244: warning: subscript has type `char'
I wish we could promote this one to be a hard error :-(. It typically
indicates (and did in this case) that someone has unportably forgotten
to cast the argument of a <ctype.h> macro to unsigned char.
> pg_lzcompress.c: In function `pglz_compress':
> pg_lzcompress.c:378: warning: inlining failed in call to `pglz_find_match'
This is not an error condition, it just means that gcc decided not to do
inlining because the called function was too big. IIRC we had some
discussion whether to specify -Winline or not, and decided to do so in
order to gather some info about whether we were overstressing "inline".
We could live with it as-is, or document somewhere (where?) that "it's
fine as long as you don't see very many of 'em", or decide that the
experiment is finished and we should take out -Winline. Comments?
> animal: osprey warnings: 22
> s_lock.c:222: warning: `tas_dummy' defined but not used
Fixing this one seems to require making tas_dummy a global name, which
does not seem like a net improvement.
> animal: lionfish warnings: 16
> /tmp/cclwN8N9.s: Assembler messages:
> /tmp/cclwN8N9.s:109082: Warning: Macro instruction expanded into
> multiple instructions
> [multiple occurrences]
This is pretty strange. It seems to occur only in files generated
from bison and/or flex. Anybody have a clue?
> scan.l:180: warning, the character range [<80>-<FF>] is ambiguous in a
> case-insensitive scanner
I commented on this already.
regards, tom lane
