This is the mail archive of the
mailing list for the GCC project.
Re: Issue with sub-object __builtin_object_size
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: jason at redhat dot com (Jason Merrill)
- Cc: jakub at redhat dot com, gcc at gcc dot gnu dot org
- Date: Tue, 16 Sep 2014 12:23:39 +0200 (CEST)
- Subject: Re: Issue with sub-object __builtin_object_size
- Authentication-results: sourceware.org; auth=none
Jason Merrill wrote:
> On 09/15/2014 11:55 AM, Ulrich Weigand wrote:
> > (https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html)
> > From the __builtin_object_size documentation, it's not immediately
> > clear to me whether this is supposed to work or not:
> > If the least significant
> > bit is clear, objects are whole variables, if it is set, a closest
> > surrounding subobject is considered the object a pointer points to.
> > Is the presence of the above cast (explicit or implicit) supposed to
> > modify the notion of "closest surrounding subobject"?
> IMO, yes. A base class subobject is a subobject, so since the least
> significant bit is set, it seems to me that GCC is correctly returning
> the size of that subobject.
I guess I'm still a bit confused about the special handling of the array
case. Even with the last bit set, array elements normally do not count
as "subobjects", so __builtin_object_size still returns the size of the
Now in this case, we cast a pointer to the array to a pointer to a base
type of the array element type -- but the intent is for the pointer to still
refer to the whole array. (Of course, this only works if the base type
is actually the same size as the array type.)
Note that with a somewhat equivalent C construct:
short int events;
short int revents;
struct pollfd x;
struct Pollfd myfd;
we still get an object size of 80 for either:
__builtin_object_size ((struct pollfd *)myfd, 1);
__builtin_object_size (&myfd->x, 1);
so there still seems to be something special in the C++ case ...
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain