I'll soon be making some improvements to the C++ call target resolution logic. However, one of the things making that change difficult is the oldFunctionWithWrappers library.

What is theFunctionWithWrappers library?

The goal of the library is to put an alert location at the outermost wrapper of a low-level function call. The idea being that this outermost function is probably the function that the developers are more familiar with. So instead of making the low-level call your sink in a dataflow configuration you make the outermost wrapper (identified via theFunctionWithWrappers library) your sink. The library will then construct a string along the lines of "function f which calls function g which calls your sink".

Why I don't like it

Honestly, I'm not really a fan of this library for a few reasons:

1. It means that whatever barrier you put in a dataflow configuration won't be considered through those wrapper functions (since you've placed the sink further away from the "real" sink).
2. It increases the number of alerts. For example, consider this example:

voidsink(int);voidwrap_sink1(int x) {sink(x);  }voidwrap_sink2(int x) {sink(x);  }voidf() {int x =source();wrap_sink1(x);wrap_sink2(x);  }

When using theFunctionWithWrappers library we'll get two alerts: one onwrap_sink1 and one onwrap_sink2. If we simply marksink as the sink we'll get 1 alert with 2 paths. This allows developers to fine-tune the number of paths via--max-paths.

This PR

So ideally I'd like to simply remove its usage from the four queries that depend on it, and deprecate this library altogether. However, that would move a bunch of primary alert locations from a wrapper function to the "real" sink in the following queries:

• cpp/path-injection (in the security-extended suite)
• cpp/sql-injection (in the security-extended suite)
• cpp/tainted-format-string (in the code scanning suite)
• cpp/command-line-injection (in the code scanning suite)

So in order to unblock my upcoming work on improvements to call target resolution logic here's a simpler alternative: we simply stop considering calls to function pointers as potential function wrappers. I actually think that's a reasonable change in itself.

The DCA looks scary because of all the alert diffs. But this really is just alert locations being moved in three queries because these alerts were previously on a wrapper function which called the "real" sink through a sequence of wrappers (where one of those calls was through a function pointer). See point 2 in the "why I don't like it" section for why this happens.

Also note that only 2 out of 330 results are in non-Samate projects.