Subject: Re: New compile warnings...

[Hal Murray]

Gary said:
> It compiles fine, until I add this:
>      export CFLAGS="-Wvla -fanalyzer"

Apologies for the noise and/or not paying attention sooner and thanks for 
opening up this can of worms.

In case anybody else hasn't looked in the man page yet...

       -Wvla
           Warn if a variable-length array is used in the code.  -Wno-vla
           prevents the -Wpedantic warning of the variable-length array.

       -fanalyzer
           This option enables an static analysis of program flow which looks
           for "interesting" interprocedural paths through the code, and
           issues warnings for problems found on them.

-------

I haven't seen any vla warnings yet.  Have you?

The ones that I now understand are possible derefrencing NULLs.  I find it a 
bit hard to understand their big complicated error message, but it's easy to 
figure things out now that I know what to look for.

  I fixed 2 actual bugs - not checking malloc.
  In 2 other cases, I added ugly hack code to keep the compiler happy.

You may get a few more if you run tests/option-tester.sh

Older/different compilers also make more warnings.  This pair is fairly common 
for my collection of toys:
../../ntpd/ntp_leapsec.c:962:5: warning: leak of FILE "farg" [CWE-775] 
[-Wanalyzer-file-leak]
../../tests/unity/unity_memory.c:104:5: warning: leak of "guard" [CWE-401] 
[-Wanalyzer-malloc-leak]

There are a couple of warnings from the parser area.  I haven't investigated.

----------

Is there a way to tell the compiler that X isn't NULL?  Or similar for other 
warnings from fanalyze?

Consider this example:

int mon_get_oldest_age(l_fp now)
{
    mon_entry * oldest;
    if (mon_data.mru_entries == 0)
        return 0;
    oldest = TAIL_DLIST(mon_data.mon_mru_list, mru);
    now -= oldest->last;
It's complaining because oldest might be NULL.  TAIL_DLIST is part of a set of 
macros for handling doubly linked lists.  The mru_entries test checks for the 
list being empty so if we get to using oldest, it won't be NULL.

I'd be happy to add a "comment" to tell the compiler not to complain.

In two cases, I added code to actually do a NULL check.  On one hand, that 
won't cost much.  On the other hand, this one gets called for every packet and 
I hate adding dumb code to the main path.  It's also clutter.  The comment is 
bigger than the code.


-- 
These are my opinions.  I hate spam.