Re: compiler warnings on the buildfarm - Mailing list pgsql-hackers
From | Chris Browne |
---|---|
Subject | Re: compiler warnings on the buildfarm |
Date | |
Msg-id | 60hco8x8u7.fsf@dba2.int.libertyrms.com Whole thread Raw |
In response to | compiler warnings on the buildfarm (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Responses |
Re: compiler warnings on the buildfarm
|
List | pgsql-hackers |
stefan@kaltenbrunner.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
pgsql-hackers by date: