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:
- A few compiler warnings Ebright, Don (Dec 23)
- Re: A few compiler warnings Michael Richardson (Dec 23)
- Re: A few compiler warnings Guy Harris (Dec 23)
- <Possible follow-ups>
- RE: A few compiler warnings Ebright, Don (Dec 23)
- Re: A few compiler warnings Guy Harris (Dec 23)
- Re: A few compiler warnings Michael Richardson (Dec 23)