tcpdump mailing list archives

RE: A few compiler warnings


From: "Ebright, Don" <Don.Ebright () compuware com>
Date: Tue, 23 Dec 2003 18:08:40 -0500

Guy,

I agree with your assesment of the futility of fixing the "const" problems
in the various native headers.

Some are perhaps a little less obviously safe, such as the AIX 
undeclared struct warnings (I don't know whether that'd break AIX 
builds on other versions of AIX).

I had checked the headers on 4.3.3 and 5.1 (the versions that are easily
available), and they are both OK FWIW.

What are some of the errors?

After peeling back a few layers of this onion, it looks like the root cause
of all of the compile errors is a problem in the configure script.  FWIW, I
believe that this system is running Tru64 5.1B based on the logon string: 

Compaq Tru64 UNIX V5.1B (Rev. 2650) 

uname -a just returns: 

OSF1 ..hostname.. V5.1 2650 alpha

All of the observed compile errors result directly or indirectly from the
compiler rejecting inline function definitions because the configure script
believed that the inline keyword was supported, but the compiler demands the
__inline form when the -std1 switch is specified.

If I change line 1142 of the configure script from 

for ac_lbl_inline in inline __inline__ __inline

to

for ac_lbl_inline in __inline __inline__ inline

to make it try the more universally acceptable __inline form first, both
libpcap and tcpdump build without errors (but with a few warnings listed
below that didn't appear when using -std).  

At this point, my best guess is that the configure script is not setting the
-std1 switch when testing whether the inline keyword is supported.  The
config.log showed no errors for the line 1136 inline test which erroneously
selected inline.  If I extract the test program code from the configure
script and execute it by itself with the -std1 switch, it fails when
defining inline and succeeds when using __inline.  Compiling with -std or
without any switches allows both forms to succeed.

With the correct __inline keyword, the only compiler warning when building
libpcap is:

cc: Info: bpf_filter.c, line 61: Macro expansion includes the token
"defined", which will be treated as an operator.  This might not be
portable. (expandeddefined)
#if defined(__hpux) || SOLARIS
-----------------------^

The compiler warnings from the tcpdump build are:

1. Tons of these:

cc: Warning: /usr/include/sys/bitypes.h, line 101: In this declaration, the
same type specifier occurs more than once. (duptypespec)
        typedef signed char               int8_t;
----------------^
cc: Warning: /usr/include/sys/bitypes.h, line 102: In this declaration, the
same type specifier occurs more than once. (duptypespec)
        typedef signed short              int16_t;
----------------^
cc: Warning: /usr/include/sys/bitypes.h, line 103: In this declaration, the
same type specifier occurs more than once. (duptypespec)
        typedef signed int                int32_t;
----------------^

2. A few typing quibbles in print-esp.c:

cc -O -std1 -O -DHAVE_CONFIG_H  -D_U_="" -I. -I./../libpcap-0.8.1
-I/usr/local/include -I./missing -I/usr/include -c ./print-esp.c
cc: Warning: ./print-esp.c, line 481: In this statement, the referenced type
of the pointer value "secret" is "char", which is not compatible with
"unsigned char" because they differ by signed/unsigned attribute.
(ptrmismatch1)
                if (EVP_CipherInit(&ctx, sa->evp, secret, NULL, 0) < 0)
--------------------------------------------------^
cc: Warning: ./print-esp.c, line 487: In this statement, the referenced type
of the pointer value "p" is const, but the referenced type of the target of
this assignment is not. (notconstqual)
                EVP_CipherInit(&ctx, NULL, NULL, p, 0);
-------------------------------------------------^
cc: Warning: ./print-esp.c, line 488: In this statement, the referenced type
of the pointer value "(p+ivlen)" is const, but the referenced type of the
target of this assignment is not. (notconstqual)
                EVP_Cipher(&ctx, p + ivlen, p + ivlen, ep - (p + ivlen));
----------------^

3. The addr_len type mismatch in print-fr.c that was also detected on the
other platforms:

cc -O -std1 -O -DHAVE_CONFIG_H  -D_U_="" -I. -I./../libpcap-0.8.1
-I/usr/local/include -I./missing -I/usr/include -c ./print-fr.c
cc: Warning: ./print-fr.c, line 216: In this statement, the referenced type
of the pointer value "&addr_len" is "int", which is not compatible with
"unsigned int" because they differ by signed/unsigned attribute.
(ptrmismatch1)
        if (parse_q922_addr(p, &dlci, &addr_len, &flags)) {
--------------------------------------^

I don't have time to chase the configure script issue further right now, but
let me know if there is something that I can do to help to narrow it down.

Regards,

Don



The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe


Current thread: