4 ms·
Tracking allocations is necessary, but not sufficient. struct S { int arr1[100]; std::string s; int arr2[100]; }; void foo(S& s) { //arr
by badmintonbaseba 2y ago
Tracking allocations is necessary, but not sufficient.
struct S {
int arr1[100];
std::string s;
int arr2[100];
};
void foo(S& s) {
//arr1 and arr2 are in the same complete object
//so they are in the same allocation
std::sort(std::begin(arr1), std::end(arr2));
}
To make it sound you really need to track arrays specifically (including implicit single-element ones), not just allocations.
It's surely somewhat feasible, as the constexpr interpreters in compilers do track it, but something like that would probably be way inefficient at runtime.
- o11c 2y ago(if `sizeof(char *)` != `sizeof(int)` it will be detected as an illegal memory access, since at a minimum every word is tagged whether it's a pointer or not. Otherwise ...) That's really an aliasing problem, not specific to arrays. The tricky part about tagging memory with a full type is that a lot of code, even in standards, relies on aliasing that's supposed to be forbidden. Still, even if the `sort` isn't detected (due to the user insisting on permissiveness rather than adding annotations), it would still detect any attempt to use `s` afterward. As for a limited array-specific solution ... I can't think of one that would handle all variants of `sort((int *)&s[0], (int *)&s[1])`. And do we want to forbid `sort(&s.arr[0], (int *)&s.s)`?