Functions vsnprintf, vsprintf and vfprintf commonly occur in DFSan warnings.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
compiler-rt/test/dfsan/custom.cpp | ||
---|---|---|
1948 | We added test cases here to verify these functions' behavior. |
vfprintf is actually a potential output point, and can be considered as a sink.
It is like __dfsw_write, and needs a callback so that users can decide whether to take this as a sink.
compiler-rt/test/dfsan/custom.cpp | ||
---|---|---|
1948 | This is what I started with but it ended up either over-complicating the test or adding duplicated code. Do you expect it's ever possible for the implementations of sprintf and vsprintf to diverge? |
compiler-rt/test/dfsan/custom.cpp | ||
---|---|---|
1948 | int sprintf_ish( char * s, const char * format, ... ) { va_list args; va_start (args, format); int r = vsprintf (s ,format, args); va_end (args); return r; } // When testing vsprintf #define PRINT sprintf_ish // When testing sprintf #define PRINT sprintf sprintf_ish is like a conversion from ... to va_list. |
compiler-rt/test/dfsan/custom.cpp | ||
---|---|---|
1948 | re "Do you expect ... to diverge?": I guess no, while testing them mainly protects dfsan_custom.cpp in case anyone changes them in the future. |
compiler-rt/test/dfsan/custom.cpp | ||
---|---|---|
1948 | Tried to share the testing code by introducing a function pointer and then passing either s(n)printf or vs(n)printf respectively. However, this seems to hit a DFSan limitation by being unable to handle indirect calls to variable-argument functions: ==57096==FATAL: DataFlowSanitizer: unsupported indirect call to vararg function snprintf The macro idea would require all the testing code for these functions to be turned into a macro as well so that we can instantiate it twice, which would be very clunky. |
Please remove vfprintf from the change's description or add a TODO in vfprintf about adding a callback to track it as an output point.
If we wanted to track output accurately, maybe fprintf also needs a callback. But this is out of the scope of this change.
We added test cases here to verify these functions' behavior.
Although internally we know it does the same as others, it would still be good to apply some tests. Can reusing sprintf's test code reduce duplicated test code?