On 12/13/23 12:00 PM, Ben Boeckel via SG15 wrote:
> On Wed, Dec 13, 2023 at 11:40:42 -0500, Tom Honermann wrote:
>> A bit of a tangent related to static analysis being ambivalent with
>> regard to libraries...
>>
>> Historically, static analysis has been blissfully unaware of program
>> composition from a linkage perspective, but there are good incentives in
>> place for that to change. Coverity now supports an integration with
>> Black Duck that allows for Coverity's build capture to record how TUs
>> are compiled to object files which are then composed into libraries
>> which are then linked into programs. The primary motivation for that
>> support is to enable software composition analysis of both source and
>> binary files used in an application. This analysis provides a bill of
>> materials that enables vulnerability assessments to be performed when
>> security weaknesses are identified in common components. A secondary
>> motivation is to enable more efficient analysis by only analyzing TU
>> groups that are actually combined into a program and to prune false
>> positives that can result when TUs that are never linked together are
>> analyzed as a group (this can happen when a primary source file is
>> compiled in multiple distinct ways for different purposes or for
>> different targets; static analysis has to pick one variant and does not
>> necessarily have sufficient information to pick the right one in the
>> absence of linkage information).
> Sure, a linker-aware static analyzer needs to know, but why can't it use
> the same "this library -> these modules" discovery path that the build
> system is using? In any case, the "play pretend" analysis doesn't have a
> library around to link to.
I believe it can. I didn't intend to imply otherwise.
>
> For example, `clang-tidy` looking at Xcode-generator sources in CMake
> when developing on my Linux machine "works" today even with the broken
> macOS SDK header includes. Sure, I get noise about `NS*` types not being
> defined, but I still get useful feedback on the general C++ source.
> Hopefully that can continue to be the case even if I end up making a
> bogus `apple.macos` module for things to use.

Sure, that is a form of graceful degradation that works to a certain
point. Depending on your perspective and needs, it is either a blessing
or a never ending source of bugs to be fixed.

Tom.

>
> --Ben
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15