Open khorben opened 1 year ago
The warning is technically correct. However, this is a common pattern, and in practice I'm not aware of this being a problem with current toolchains. What is definitely a problem is doing something along the lines of:
q = realloc(p, ...);
foo = foo + (q - p);
because that doesn't give foo the right provenance, and that's something that the recently-added _FORTIFY_SOURCE=3 in GCC supposedly catches, as does CHERI. But the code isn't doing that, the provenance is correct, the issue is just that, strictly, the value of the pointer given to realloc is now indeterminate^1, which isn't particularly helpful, nor is it really necessary to be specified like that. In this case, one could trivially address the issue by hoisting the t - old_token
calculation before the realloc (and remove the now-obsolete old_token), and let the compiler decide to sink it back to its use, which it will surely do. I would expect identical code to be generated.
^1 C99 6.2.4p2: "The value of a pointer becomes indeterminate when the object it points to reaches the end of its lifetime."
When compiling with
-Wuse-after-free=2
, GCC catches the following problem inparse.c
from the 1.8.3 release:After reading it, I believe the corresponding code is harmless, since it never actually dereferences
old_token
. It is however very inelegant in the way it performs pointer arithmetic to keep track oft
, and should probably be modified to use an array index instead.