2016-03-01 13:44 GMT+01:00 Holger Hoffstätte <holger.hoffstae...@googlemail.com>: > Hi, > > With btrfs-progs needing & getting some more love I decided to run today's > master through clang's very awesome static analyzer [1] to see what a more > complete data flow analysis than gcc's -Wall yields. The results can be > found at [2] and are somewhat reason for concern. =:) > > Please note that even though all messages are typically "real" in the sense > that they _could_ happen, it does not mean that they do during normal > operation, since some codepaths might just be dynamic/rare. That being said, > quite a few warnings seemed sufficiently serious to me that I decided to post > this. For example there's IMHO no sane way zero-sized allocations make any > sense. >
All zero-sized allocations are false positives, except the btrfs-image.c. This can be fixed by placing the num_threads at the top instead of after calloc(). > IMHO most dead stores are seemingly the easiest to fix (just remove the > statement?), but some of them might actually be missing upstream error > handling - indicative of something more serious. I checked a few, those were false positives. > Dave, any suggestions on how best to proceed? Any preferences or would > another branch be more interesting? I tried to track devel but that > gets rebased frequently (or I'm doing something wrong). > > Btw running scan-build is easy: get clang, './configure' as usual and > 'scan-build make -jX' will create the report in /tmp/scan-build-<time>. > > Let me know if this is helpful. > > cheers, > Holger > > [1] http://clang-analyzer.llvm.org/scan-build.html > [2] > http://hoho.duckdns.org/~holger/btrfs-progs/scan-build-2016-03-01-130244-29106-1/ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
