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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: non-blocking CREATE INDEX in 8.2??
Next
From: "Affan Salman"
Date:
Subject: Re: FK Deferred RI Triggers & SAVEPOINTs --- A"C"ID violation