C++: Don't wrap calls through function pointers in FunctionWithWrappers

[MathiasVP]

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 old FunctionWithWrappers library.

What is the FunctionWithWrappers 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 the FunctionWithWrappers 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:

  void sink(int);
  void wrap_sink1(int x) {
    sink(x);
  }

  void wrap_sink2(int x) {
    sink(x);
  }

  void f() {
    int x = source();
    wrap_sink1(x);
    wrap_sink2(x);
  }

When using the FunctionWithWrappers library we'll get two alerts: one on wrap_sink1 and one on wrap_sink2. If we simply mark sink 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.

[Copilot]

Pull Request Overview

This PR modifies the FunctionWithWrappers library to exclude calls through function pointers from being considered as wrapper functions. The change aims to simplify the library's behavior while unblocking upcoming improvements to call target resolution logic.

• Restricts wrapper function detection to direct function calls only (excluding function pointer calls)
• Updates change notes to document the impact on affected security queries
• Maintains the library's core functionality while reducing complexity

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
cpp/ql/lib/semmle/code/cpp/security/FunctionWithWrappers.qll	Changes Call to FunctionCall in two predicates to exclude function pointer calls
cpp/ql/lib/change-notes/2025-07-16-FunctionWithWrappers.md	Documents the library change for developers
cpp/ql/src/change-notes/2025-07-16-FunctionWithWrappers.md	Documents potential alert location changes in affected queries

[jketema]

Looks sensible. One question.

[jketema]

Do we still need resolveCall here, or can we just do getTarget now?

[MathiasVP]

We can probably do getTarget, yeah. Will try it out!

[MathiasVP]

Fixed in 8b953e4

[jketema]

Same as above.

[MathiasVP]

Fixed in 8b953e4

[jketema]

LGTM