```cpp
char* source();
void sink(const char*);
int sprintf(char *, const char *, ...);
void call_sprintf(char* path, char* data) {
sprintf(path, "%s", "abc"); // (1)
sprintf(path, "%s", data); // (2)
}
void foo() {
char path[10];
call_sprintf(path, source()); // (3)
sink(path);
}
```
we identify that the `*path [post update]` node at `// (2)` is a
`ReturnNodeExt` and since `*data` flows to that node flow will be carried
out to `*path [post update]` at // (3) and thus reach `sink(path)`.
The reason `*path [post update]` at `// 2` is recognized as a `ReturnNodeExt`
is because it satisfies the following condition (which is identified by the
shared dataflow library):
There is flow from the parameter node `*path` to the pre-update node of the
post-update node `*path [post update]` at `// (2)`.
However, when we start recognizing that the call to `sprintf(path, ...)` at
`// (1)` overrides the value of `*path` and no longer provide use-use flow out
of `*path` the `*path [post update]` node at `// (2)` is no longer recognized
as a `ReturnNodeExt` (because it doesn't satisfy the above criteria).
Thus, we need to identify the flow above without relying on the dataflow
library's summary mechanism. That is, instead of relying on the dataflow
library's mechanism to summarize the `*data -> *path` flow for `call_sprintf`
we need to:
- Ensure that the write to `*path` at `// (2)` is recognized as the "final"
write to the parameter, and
- Ensure that there's flow out of that parameter and back to
`*path [post update]` at `// (3)`.
Luckiky, we do all of this already to support flow out of writes to parameters
that don't have post-update nodes. For example, in something like:
```cpp
void set(int* x, int y) {
*x = y;
}
void test() {
int x;
set(&x, source());
sink(x);
}
```
So in order to make the original example work, all we need to do is to remove
the restrictions on this mechanism so that the same mechanism that makes the
above example work also makes the original example work!
Previously, we had a `sh_test` wrapping the `java_test` to do some setup.
This was extremely brittle on Windows, and relied on getting a deploy
jar from `java_test`. This breaks when updating to Bazel 7, where the
ability to get a deploy jar from `java_test` was removed.
Therefore, we now do all the test setup in `AllTests.java` instead.
This is much cleaner, and shouldn't break as easily.
