Re: compiler warnings on the buildfarm

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

In response to

Responses

Browse pgsql-hackers by date

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