C++: Fix global flow without an SSA definition

[MathiasVP]

Turns out we didn't create an GlobalUse node (which represents the use of a global variable after exiting a function body) when there was just a store step to the global variable.

Commit-by-commit review recommended.

[MathiasVP]

Hmm... Lots of new results and quite a bad performance regression. Will convert this PR to a draft and investigate 👀.

[geoffw0]

I just took a look at the first few new results locally, so that I could see the full flow paths etc and assess.

• cpp/cleartext-storage-file on git-linux was already a result (with source credential.c line 207), this change adds an additional source for that result (imap-send.c line 955). The path I checked was long but looks plausible. TP I think.
• cpp/command-line-injection on vim__vim; 478 results all on the same line of code. I failed to find the new one. Not sure what's going on here.
• cpp/non-constant-format on vim__vim; this is not a path problem but involves macros; I think it's a false positive due to the underscore macro, which the query attempts to treat as a barrier / constant string. Have we accidentally worked around that?
• cpp/path-injection on Nelson-numerical-software__nelson; three new results; like cpp/cleartext-storage-file on git-linux, these are results we already had but an additional source is associated with each of them. All the new taint flows are similar to each other, and look OK except:
  • gram.c line 1410 writes the tainted data into yyval.extval but it's read on gram.c line 979 as yypt[-0].yyv.charpval, a different member of the union. Whether that's reasonable depends on how the union is used, I suppose. I lean towards yes, it's reasonable taint flow.
  • flow appears to go on names.c line 781 from stateno to extsymtab[-1-stateno].fextname, which seems a little dubious to me, I'm not sure.

[MathiasVP]

Thanks for looking at these results, Geoffrey. I just did a rebase to bring this PR back onto the latest main. Will run another DCA to see if the performance has improved due to all the changes we've done since I first tried this change 🤞

[geoffw0]

DCA:

• analysis time on the new run is 5% slower, whereas on the old run it was 6% slower. So that looks like an improvement but there still appears to be a significant slowdown (if the numbers from DCA are reliable).
• the number of results changes is down as well, from 467 to 70. Is this expected?
• both runs have a bunch of failed projects, which potentially limits the value of comparing them.

I'm happy to review some more result changes at the right time, but I'd like a bit more context.

[MathiasVP]

DCA:

• analysis time on the new run is 5% slower, whereas on the old run it was 6% slower. So that looks like an improvement but there still appears to be a significant slowdown (if the numbers from DCA are reliable).

DCA numbers are pretty reliable, yes. The vim, wireshark and php are consistent with what earlier DCA runs showed. So there's definitely still a problem.

• the number of results changes is down as well, from 467 to 70. Is this expected?
• both runs have a bunch of failed projects, which potentially limits the value of comparing them.

Indeed, since a number of projects failed I don't think we can compare the query result changes just yet.

I'm happy to review some more result changes at the right time, but I'd like a bit more context.

There's not a whole lot of context other than the added test that fails in dbfea8e and works in 87b6c5a, but I'll be sure to add some more description to the PR once I pull it out of draft.