From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: compiler warnings on the buildfarm |
Date: | 2007-07-13 22:00:32 |
Message-ID: | 60hco8x8u7.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
stefan(at)kaltenbrunner(dot)cc (Stefan Kaltenbrunner) writes:
> 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.
Hmm. Logging onto grebe:
/usr/include/sys/socket.h:int getpeereid(int, uid_t *__restrict__, gid_t *__restrict__);
ydb1.int.libertyrms.com(cbbrowne): /home/cbbrowne # egrep '_(check|clear)_lock' /usr/include/*/*.h
/usr/include/sys/atomic_op.h:boolean_t _check_lock();
/usr/include/sys/atomic_op.h:void _clear_lock();
/usr/include/sys/atomic_op.h:void _clear_lock_mem();
/usr/include/sys/atomic_op.h:boolean_t _check_lock(atomic_p, int, int);
/usr/include/sys/atomic_op.h:void _clear_lock(atomic_p, int);
/usr/include/sys/atomic_op.h:void _clear_lock_mem(atomic_p, int);
Do those seem apropos?
>>> 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.
/* According to RFC3493 sockaddr_storage structure should be greater than or
equal to the largest sockaddr struct. The size of sockaddr_un structure changed to 1025 in order to support long user names. Change _SS_MAXSIZE accordingly
inorder to main compliance to the RFC */
#define _SS_MAXSIZE 1280 /* Implementation specific max size */
Actually, you can take a look at doc/FAQ_AIX; that reports that the
size was updated to 1028 back in 2005, as a result, in fact, of my bug
submission :-).
The comment in the #include seems somewhat nonsensical; the reason for
increasing sockaddr_un was to support IPv6 addresses. I didn't think
it had anything to do with user names...
[Aside: Sorry, I don't have any flames about EDB/CMD today. Boy, you
miss reading -advocacy for half a day, and sometimes you miss
something big...]
--
output = reverse("gro.mca" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"One of my most often repeated quips was the one I made when former
Presidents Carter, Ford and Nixon stood by each other at a White House
event. 'There they are,' I said. 'See no evil, hear no evil, and ...
evil.'" -- Bob Dole, 1983
From | Date | Subject | |
---|---|---|---|
Next Message | Affan Salman | 2007-07-13 23:48:02 | Re: FK Deferred RI Triggers & SAVEPOINTs --- A"C"ID violation |
Previous Message | Jim C. Nasby | 2007-07-13 21:47:21 | Re: non-blocking CREATE INDEX in 8.2?? |