C PSA/periodic reminder: YOU CANNOT CALL A VARIADIC FUNCTION VIA AN EXPRESSION OF NON-VARIADIC FUNCTION TYPE MATCHING THE ARGS YOU WANT TO USE, OR VICE VERSA!
Conversation
Replying to
By casting a function pointer? I'd never even thought to try it, but now that you mention it, I certainly wouldn't expect it to work, though it might by accident on ancient systems that always pass args on stack.
1
Replying to
That, or by a declaration in one translation unit mismatching the definition in another.
2
Unfortunately Clang / GCC don't have a way to find these bugs unless it's done via a function pointer.
1
No, because C type information is lost compiling to bytecode. There's no error even with a more egregious violation. Needs a compile-time sanitizer.
% cat a.c
int foo(void) {
return 1;
}
% cat b.c
void foo(int x);
void bar() {
foo(5);
}
% clang a.c b.c -flto -shared
2
CFI can be used to catch it for function pointers though. Here's an example:
gist.github.com/thestinger/963
By default, it's set up in the trapping mode so for using it as a debugging feature, you need to disabling trapping to use the debug runtime and enable recovery for the runtime.
1
1
They added CFI as a security hardening feature and the debugging runtime support was implemented primarily for finding the bugs in order to enable it in production for hardening. It would make sense to have an UBSan sanitizer for finding the same mismatches with direct calls.
You’d need each callee to know it’s own type, and each caller to check that what it’s calling is indeed what it thinks. Doesn’t seem in line with what UBSan does (i.e. needs storage, needs to work for the entire process).
Unless you had something else in mind?
1
1
It could diagnose all the issues at link-time when using LTO. It might not make sense to call that a sanitizer. It wouldn't work across dynamic library boundaries without adding actual metadata in the binary and linker support but that's not required for it to be useful.
2
1
Show replies