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