kees wrote:
> ```
> int foo(struct s *p, int index) {
> return __builtin_dynamic_object_size((++p)->array[index], 1);
> }
> ```
>
> This _shouldn't_ increment `p`, but we need to get the array size of the
> element _after_ `p`. I suspect that this is probably a horrible security
> violation in the making, but we at least need to handle such an eventuality
> gracefully. For a first pass, I think returning `-1` or `0` (depending on the
> default return value) for _any_ pointer arithmetic is probably okay...maybe
> even the best option?
>
> @kees Thoughts?
Owch. That really shouldn't be legal: we can't have arrays of structs ending in
a FAM, so the `++p` isn't sane. That said, I guess pointer arithmetic must
follow `sizeof`, so `++p` isn't illegal; it's just awful. FWIW, GCC just
returns `SIZE_MAX` for this sort of "aaah, where are you going?!" insanity for
non-FAM structs. But Clang appears to just go along for the ride:
https://godbolt.org/z/Pss1oz7sW
So that needs to be fixed in Clang too.
But for doing a FAM struct like this ... my instinct is to say it should return
0, much like requesting an out of bounds array index. (Rather than `SIZE_MAX`.)
https://github.com/llvm/llvm-project/pull/73730
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
