Re: A few compiler warnings

[Guy Harris <guy () alum mit edu>]

On Dec 23, 2003, at 3:08 PM, Ebright, Don wrote:

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

OK - Michael, should we just make that change?  (I think I've done 
builds that didn't get those warnings - those might've been on 
pre-4.3.3 versions of AIX.  I guess if somebody has a problem we could 
have the configure script check for that header file....)

> > 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).

I remember seeing a problem with the inlining stuff on some platform, 
but I think it was an HP-UX issue; I might've seen some mention of the 
DU/T64U problem, but I'm not sure.

This might be the result of change 1.76 in libpcap's aclocal.m4 and 
change 1.84 in tcpdump's aclocal.m4 - both of which are new in 0.8/3.8. 
 (The change was done in an attempt to deal with the HP-UX inlining 
issues, although I think they didn't handle all the issues.)

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

Changing the AC_LBL_C_INLINE macro to temporarily set CFLAGS to include 
V_CCOPT before the loop and restoring it afterwards should fix that 
problem - and might even fix some of the HP-UX problems, as it might 
not have been properly testing inlining if there's some compiler option 
that controls how the HP compiler handles inlining and it's being seet 
in V_CCOPT, e.g "-Aa".

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

Yeah, perhaps we should do

        #if defined(sun) && (defined(__SVR4) || defined(__svr4__))
        #define SOLARIS
        #endif

and replace "SOLARIS" in subsequent #ifs with "defined(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;
> ----------------^

Those showed up in Albert Chin's logs, too.  I'm not sure what the 
problem is, unless "int{8,16,32}_t" are #defined as "signed 
{char,short,int}" on DU/T64U.  If so, the problem might be that the 
AC_LBL_CHECK_TYPE macro isn't #including enough header files to pick up 
those definitions.

> 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));
> ----------------^

I think I remember somebody saying that's a API issue with some 
library.  It might've been itojun; he seems to have noted something 
about openssl 0.9.6 -> 0.9.7 in a message in some other list talking 
about constification issues:

        http://mail-index.netbsd.org/tech-crypto/2003/06/29/0000.html

Googling for

        EVP_Cipherinit const 0.9.6 0.9.7

found some other stuff suggesting API changes (possibly *incompatible* 
changes):

        http://www.mail-archive.com/openssl-dev () openssl org/msg10688.html

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

I'd vote for fixing that.

-
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