Are there undefined behaviors that escape fsanitize in clang/gcc?-CodePudding

Question about undefined behavior in C/C : if I compile a program, say, file.c, with:

clang/gcc -g -fsanitize=address,undefined,signed-integer-overflow -fno-sanitize-recover=all file.c

And the program runs and terminates normally, can I assume that this program did not incur in any undefined behavior during that execution? If that is not the case, and an undefined behavior is still possible, could you give me a counter example? And, is there a way to catch this undefined behavior? Perhaps using RV-Match?

CodePudding user response：

Are there undefined behaviors that escape fsanitize in clang/gcc?

Yes, of course.

can I assume that this program did not incur in any undefined behavior during that execution?

No.

If that is not the case, and an undefined behavior is still possible, could you give me a counter example?

There are many, many, many, many such examples. Dunno, for example this idea:

int __; int main() { return 0; }

Compiles cleanly on gcc12.1 and clang14.0 with -fsanitize=address,undefined,signed-integer-overflow -fno-sanitize-recover=all --pedantic -Wall -Wextra -ansi. Yet, contains an identifier that starts with two underscores, which is undefined behavior.

is there a way to catch this undefined behavior?

I would say it is not proven if it is possible or not to catch all possible undefined behaviors.

CodePudding user response：

The Standard was never written to unambiguously partition all program executions into those which exhibit Undefined Behavior and those which do not. No tool could possibly identify all of the program executions that an implementation might conceivably process nonsensically, without also flagging many program executions which all practical implementations would in fact process consistently.

This is especially true many situations involving restrict. Whether constructs have defined behavior or not will often depend upon whether changing some pointer Q so it points to a copy of the same data would change the value produced by evaluating some other pointer expression P. While there are times when this definition will sensibly recognize some pointer P as being unambiguously based upon Q, and there are times when it will sensibly recognize some pointer P as unambiguously not based upon Q, there are times when it does neither. The question of whether a program's behavior is defined in such circumstances may be essentially unanswerable, and thus an implementation could not plausibly be expected to answer it.