Re: compiler warnings on the buildfarm

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> ok I did that for a few members (removing all the statement not reached
> ones as well as some purely informal notices and all the flex related
> warnings) and came up with something similiar to:

I've cleaned up most of this first batch. Open issues are:

> animal: eel warnings: 4
> dirmod.c:206: warning: no previous prototype for 'pgsymlink'

Somebody needs to figure out whether we are supposed to be using
pgsymlink on Cygwin.

> animal: clownfish warnings: 12
> "dynloader.c", line 4: warning: empty translation unit
> "postgres.c", line 3758: warning: loop not entered at top

The first of these is not a bug, the second seems to be some weird
aberration in their statement-not-reached detection.

> animal: grebe warnings: 45
> xlog.c:651: warning: implicit declaration of function '_check_lock'
> xlog.c:654: warning: implicit declaration of function '_clear_lock'
> hba.c:1449: warning: implicit declaration of function 'getpeereid'

Someone needs to find out which system headers declare these functions
on AIX.

> ip.c: In function 'getaddrinfo_unix':
> ip.c:254: warning: large integer implicitly truncated to unsigned type

This is complaining about

#ifdef HAVE_STRUCT_SOCKADDR_STORAGE_SS_LEN
unp->sun_len = sizeof(struct sockaddr_un);
#endif

I don't know how wide sun_len is on this platform. It's probably uint8,
but if we explicitly cast the sizeof to 8 bits, we could conceivably
break things on other platforms. Are there any where sockaddr_un is
longer than 255 bytes? Anyway I'm inclined to leave this alone.

> guc.c:2866: warning: 'guc_get_index' defined but not used
> Extra instructions are being generated for each reference to a TOC
> symbol if the symbol is in the TOC overflow area.

This is fairly bizarre, since 'guc_get_index' *is* used in guc-file.c,
which is included into this same file. However I don't much like the
coding method used here (it is certainly not better than using a
temporary flag bit), so when I get a chance I'll rewrite it out of
existence.

> connect.c:23: warning: missing braces around initializer
> connect.c:23: warning: (near initialization for
> 'actual_connection_key_once.__on_word')
> misc.c:67: warning: missing braces around initializer
> misc.c:67: warning: (near initialization for 'sqlca_key_once.__on_word')

I think these are a platform bug. The spec clearly says that

static pthread_once_t actual_connection_key_once = PTHREAD_ONCE_INIT;

is exactly how you are supposed to do it. If pthread_once_t is a struct
on a given platform, that platform ought to be defining
PTHREAD_ONCE_INIT with the appropriate braces included. If we added
braces ourselves we'd break it for platforms where the macro is correct
already. Hence, not our problem.

regards, tom lane