Issues reported by static analysis

[telans]

Static analysis through scan-build and Clang/LLVM 12.0.0-rc1:

scan-build: Using '/usr/lib/llvm/12/bin/clang-12' for static analysis
/usr/lib/llvm/12/bin/../libexec/ccc-analyzer -Wall -std=gnu90  -c -o compsize.o compsize.c
/usr/lib/llvm/12/bin/../libexec/ccc-analyzer -Wall -std=gnu90  -c -o radix-tree.o radix-tree.c
compsize.c:124:10: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption [alpha.core.CastToStruct]
    ei = (struct btrfs_file_extent_item *) bp;
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compsize.c:206:16: warning: Casting a non-structure type to a structure type and accessing a field can lead to memory access errors or data corruption [alpha.core.CastToStruct]
        head = (struct btrfs_ioctl_search_header*)bp;
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compsize.c:281:26: warning: Null pointer passed to 1st parameter expecting 'nonnull' [core.NonNullParamChecker]
                    de = readdir(dir);
                         ^~~~~~~~~~~~
compsize.c:455:9: warning: Potential leak of memory pointed to by 'ws' [unix.Malloc]
        print_help();
        ^~~~~~~~~~
4 warnings generated.
/usr/lib/llvm/12/bin/../libexec/ccc-analyzer -Wall -std=gnu90  -o compsize compsize.o radix-tree.o
scan-build: Analysis run complete.
scan-build: 4 bugs found.

compsize-scan-build.tar.gz

See the attached file/html pages for an interactive view of function paths taken (or just run scan-build -V make with alpha checkers yourself). Not sure if any of these are actually issues but I thought you may be interested.

[kilobyte]

So it looks like clang 12's static analyzer is no better than gcc 11's. Which, sad to say, is basically useless at this version.

Out of the four issues you listed:

• two are bogus in a somewhat non-obvious way (all accesses go through unaligned+possible-bad-endian conversion), but everything is still available from this unit of compilation, via static functions only
• one is trivially bogus in a way that shouldn't confuse any static analyzer: the variable dir is checked before entering the loop, and not assigned afterwards
• one could be in theory valid — but only if main() gets called by something other than glibc's entry code