Nmap Development mailing list archives

Nmap 7.50 GCC 6 warnings


From: Victor Coss via dev <dev () nmap org>
Date: Wed, 5 Jul 2017 13:24:34 -0400

Hello, when I compiled Nmap 7.50 on the latest Debian Stretch (9) using
GCC version, gcc (Debian 6.3.0-18) 6.3.0 20170516, I have noticed the
following warnings. They were easy to notice as they light up different
colors.

make[2]: 'liblua.a' is up to date.
make[2]: Leaving directory '/opt/nmap-7.50/liblua'
gcc -I./../liblua  -I../libpcap -DHAVE_CONFIG_H
-DNCAT_DATADIR="\"/usr/local/share/ncat\"" -D_FORTIFY_SOURCE=2 -I. -I..
-I../nsock/include/ -I../nbase -DLUA_USE_POSIX -DLUA_USE_DLOPEN
-DHAVE_LUA=1 -I../liblua -g -O2 -Wall -c ncat_main.c -o ncat_main.o
gcc -I./../liblua  -I../libpcap -DHAVE_CONFIG_H
-DNCAT_DATADIR="\"/usr/local/share/ncat\"" -D_FORTIFY_SOURCE=2 -I. -I..
-I../nsock/include/ -I../nbase -DLUA_USE_POSIX -DLUA_USE_DLOPEN
-DHAVE_LUA=1 -I../liblua -g -O2 -Wall -c ncat_connect.c -o ncat_connect.o
ncat_connect.c: In function ‘read_stdin_handler’:
ncat_connect.c:1219:7: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
       if (!o.noshutdown)
       ^~
ncat_connect.c:1222:9: note: ...this statement, but the latter is
misleadingly indented as if it is guarded by the ‘if’
         if (o.proto != IPPROTO_TCP || (o.proto == IPPROTO_TCP &&
o.sendonly))
         ^~
gcc -I./../liblua  -I../libpcap -DHAVE_CONFIG_H
-DNCAT_DATADIR="\"/usr/local/share/ncat\"" -D_FORTIFY_SOURCE=2 -I. -I..
-I../nsock/include/ -I../nbase -DLUA_USE_POSIX -DLUA_USE_DLOPEN
-DHAVE_LUA=1 -I../liblua -g -O2 -Wall -c ncat_core.c -o ncat_core.o


When doing research, it appears this is due to changes with the new GCC
6. I found the following information on GCC's site (link to page
<https://gcc.gnu.org/gcc-6/porting_to.html>) about porting to GCC 6,


    -Wmisleading-indentation

A new warning |-Wmisleading-indentation| was added to |-Wall|, warning
about places where the indentation of the code might mislead a human
reader about the control flow:

    *sslKeyExchange.c:* In function *'SSLVerifySignedServerKeyExchange'*:
    *sslKeyExchange.c:629:3:* warning: this *'if'* clause does not guard... [-Wmisleading-indentation]
        if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        ^~
    *sslKeyExchange.c:631:5:* note: ...this statement, but the latter is misleadingly indented as if it is guarded by 
the *'if'*
            goto fail;
            ^~~~

This has highlighted genuine bugs, often due to missing braces, but it
sometimes reports warnings for poorly-indented files, or on projects
with unusual indentation. This may cause build errors if you have |-Wall
-Werror| in your project.

The best fix is usually to fix the indentation of the code to match the
block structure, or to fix the block structure by adding missing braces.
If changing the source is not practical or desirable (e.g. for
autogenerated code, or to avoid churn in the source history), the
warning can be disabled by adding |-Wno-misleading-indentation| to the
build flags. Alternatively, you can disable it for just one part of a
source file or function using pragmas:

|#pragma GCC diagnostic push #pragma GCC diagnostic ignored
"-Wmisleading-indentation" /* (code for which the warning is to be
disabled) */ #pragma GCC diagnostic pop |

Source files with mixed tabs and spaces that don't use 8-space tabs may
lead to warnings. A real-world example was for such a source file, which
contained an Emacs directive to view tabs to be 4 spaces wide:

      /* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */

The mixture of tabs and spaces did correctly reflect the block structure
when viewed in Emacs, but not in other editors, or in an HTML view of
the source repository. By default, |-Wmisleading-indentation| assumes
tabs to be 8 spaces wide. It would have been possible to avoid this
warning by adding |-ftabstop=4| to the build flags for this file, but
given that the code was confusing when viewed in other editors, the
indentation of the source was fixed instead.


_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

Current thread: