How should `__builtin_object_size` treat casts in the `type & 1 == 1` case?

[zygoloid]

Originally posted by @bwendling in #96573 (comment):

I have a question about the "sub-object" part. Do we attempt to discover the sub-object past any casting? A motivating example:

char mux[10][10][10];

printf("%ld\n", __builtin_dynamic_object_size(&((char *)&mux[1][1])[var], 1));

GCC prints 89 (when var is 1). In the changes I'm making to the sub-object calculations, I want to say that this should print 9, because the sub-object is mux[1][1] and not a one-dimensional array. There could be arguments made for both options, so I'd like to get everyone's opinions.

[zygoloid]

I think the best point of reference that I know on the C++ side is the (work in progress, possibly abandoned?) WG21 committee paper P1839R5. While that isn't part of the C++ standard, it has been through several rounds of committee review and gives us some guidance about what they're thinking. In particular, it says that, while you can get from &mux[1][1] to both the char[10] it points to and the eight char[10]s after it in the same array, the casted version (char*)&mux[1][1] produces a pointer to the first element of the object representation of that char[10], which is an array of 10 unsigned chars in this case, and thus &((char *)&mux[1][1])[var] is only in bounds when 0 <= var < 10.

So I think that under P1839R5's model, your example should give 9 not 89. But maybe that's too language-lawyery. What behavior makes most sense for _FORTIFY_SOURCE?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Richard Smith (zygoloid)

_Originally posted by @bwendling in https://github.com//issues/96573#issuecomment-2190396880_:

> I have a question about the "sub-object" part. Do we attempt to discover the sub-object past any casting? A motivating example:
>
> c > char mux[10][10][10]; > > printf("%ld\n", __builtin_dynamic_object_size(&((char *)&mux[1][1])[var], 1)); >
>
> GCC prints 89 (when var is 1). In the changes I'm making to the sub-object calculations, I want to say that this should print 9, because the sub-object is mux[1][1] and not a one-dimensional array. There could be arguments made for both options, so I'd like to get everyone's opinions.

[kees]

I would agree with the "9" result here. It is what I'd expect from __bos(..., 1) which is the "smallest subobject". In the example, if you wanted to include the adjacent following arrays, the addressing would need to be moved up a level.

I've been surprised by this "too big" result a few times when doing the FORTIFY work in the kernel, as this result was allowing memcpy to cross over into the neighboring objects, which is the very thing FORTIFY is trying to prevent. :)

[bwendling]

For the sake of consistency between C++ and C, I'll go forward with the "9" result. Thanks for the confirmation!

[bwendling]

See pr86858.