Current gcc warnings on ia64, hppa and sparc

Russ Allbery rra at stanford.edu
Sat Jun 29 22:08:17 UTC 2013


Julien ÉLIE <julien at trigofacile.com> writes:

> network.c: In function 'network_sockaddr_sprint':
> network.c:648: warning: cast increases required alignment of target type
> network.c:662: warning: cast increases required alignment of target type
> network.c: In function 'network_sockaddr_equal':
> network.c:680: warning: cast increases required alignment of target type
> network.c:681: warning: cast increases required alignment of target type
> network.c:684: warning: cast increases required alignment of target type
> network.c:685: warning: cast increases required alignment of target type
> network.c:692: warning: cast increases required alignment of target type
> network.c:693: warning: cast increases required alignment of target type
> network.c: In function 'network_sockaddr_port':
> network.c:729: warning: cast increases required alignment of target type
> network.c:736: warning: cast increases required alignment of target type

These are all harmless.  The complier just doesn't have enough information
to know that they're safe.  They're all cases where the function takes a
generic struct sockaddr, checks sa_family, and based on the results, casts
the pointer to either struct sockaddr_in or struct sockaddr_in6.  This is
guaranteed to be safe provided that the original structure was actually a
sockaddr_in or sockaddr_in6, matching its sa_family, and if that isn't
true, the caller has violated the socket API contract.

In the current rra-c-util, I've added (const void *) casts before the
final casts for all of those assignments to try to suppress the warnings,
as in:

        sin6 = (const struct sockaddr_in6 *) (const void *) addr;

in network_sockaddr_sprint.  However, I don't know if that actually worked
since I don't have a system that issues this warning on which I can easily
test.

(Unfortunately, it's not trivial to just resynchronize from rra-c-util for
this file because the INN version also has the innbind machinery.  For
easier synchronization, that should be moved into another INN-specific
wrapper that calls into the generic code.)

> Test suite
> ----------

> ../lib/getaddrinfo.c: In function 'gai_addrinfo_new':
> ../lib/getaddrinfo.c:204: warning: cast increases required alignment of target type
> ../lib/getaddrinfo.c:205: warning: cast increases required alignment of target type
> ../lib/getaddrinfo.c:206: warning: cast increases required alignment of target type
> ../lib/getaddrinfo.c:207: warning: cast increases required alignment of target type

Same problem here, although the current rra-c-util hasn't tried to solve
it.  However, this could be fixed through some restructuring of the code
so that it allocates the struct sockaddr_in separately and assigns
directly to it, and then stores the pointer in the ai->ai_addr struct
member instead of using casts.  If I get a chance, I'll rewrite it that
way, since it makes the code somewhat more straightforward.

> lib/getaddrinfo-t.c: In function 'main':
> lib/getaddrinfo-t.c:74: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:84: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:97: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:112: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:138: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:152: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:165: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:177: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:193: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:210: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:220: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:233: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:256: warning: cast increases required alignment of target type
> lib/getaddrinfo-t.c:269: warning: cast increases required alignment of target type

These, on the other hand, are unavoidable and correct.  Here too I don't
know if casting to void * first would suppress the warning.

> ../lib/getnameinfo.c: In function 'test_getnameinfo':
> ../lib/getnameinfo.c:151: warning: cast increases required alignment of target type

Same problem.

> lib/network-t.c: In function 'listener_any':
> lib/network-t.c:116: warning: cast increases required alignment of target type

Same problem.

> libtest.o(.text+0x408): In function `test_file_path':
> /home/iulius/autobuild/inn/inn2/inn-CURRENT-20130619/tests/libtest.c:563: warning: sprintf() is often misused, please use snprintf()

> runtests.o(.text+0x32c): In function `find_test':
> /home/iulius/autobuild/inn/inn2/inn-CURRENT-20130619/tests/runtests.c:929: warning: sprintf() is often misused, please use snprintf()

> lib/inet_ntoa.o(.text+0x3c): In function `test_inet_ntoa':
> ../lib/inet_ntoa.c:33: warning: sprintf() is often misused, please use snprintf()

> lib/messages-t.o(.text+0xdd4): In function `main':
> lib/messages-t.c:277: warning: sprintf() is often misused, please use snprintf()

> lib/snprintf-t.o(.text+0x5cc): In function `main':
> lib/snprintf-t.c:168: warning: sprintf() is often misused, please use snprintf()

These are all rather annoying since snprintf isn't fully portable or
guaranteed to be available, and all of this code is written to be
extremely portable (with the possible exception of lib/messages-t.c, which
could probably do without being this portable).  lib/snprintf-t.c in
particular is comparing the results of the local snprintf against sprintf
to be sure that it works properly.

I'm not sure what I'm going to do when this error becomes widespread.
I'll probably consider just dropping support for any platform that doesn't
have a working snprintf in my code (which means, among other things,
Solaris 9, some versions of HP-UX 11, and some versions of IRIX 6.5).  But
I kind of hate to do that.  I suppose I could open-code a string
concatenation routine in runtests, but bleh.

All of the uses of sprintf above are, of course, safe.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list