Re: compiler warnings on the buildfarm

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Christopher Browne <cbbrowne(at)ca(dot)afilias(dot)info>
Subject: Re: compiler warnings on the buildfarm
Date: 2007-07-13 07:05:57
Message-ID: 46972455.8030208@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
[...]
>> 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.

will see about filtering out those

>
>> 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.

no idea on AIX but I have added christopher to the CC list - maybe he
can shed some light on those things.

>
>> 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.

I see

Stefan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2007-07-13 07:17:46 Re: compiler warnings on the buildfarm
Previous Message Stefan Kaltenbrunner 2007-07-13 07:02:33 Re: compiler warnings on the buildfarm