bwendling wrote: > > This is why I believe the gcc behavior is correct. When it knows the size > > given to `malloc` it uses that. When it doesn't know that it simply returns > > INT_MAX. When you ask gcc for the `__bdos` of the FAM it will use the > > `count` to calculate the size. > > (nit: `SIZE_MAX`, not `INT_MAX`) > > AIUI, GCC considers this to be a bug in the face of `counted_by`. The reason > GCC returns "unknown" (`SIZE_MAX`) in the case of a pointer like that is > because (prior to `counted_by`) if the pointer wasn't to local storage, it > could no know if it was a singleton or not. i.e. it may be pointing into a > larger array of objects, so it cannot know the size. (This is most clear for > `char *` variables, for example.)
[snip] > This shows how GCC will adjust the `__bdos` when it is certain of the object > being a singleton, but it still missing the "counted_by requires a singleton" > logic. (See also `-Wflexible-array-member-not-at-end` in GCC). It also shows > that Clang's `__bdos` can be lied to. For what it's worth, GCC's return value isn't wrong, according to them. They want to return *something* when `__bdos` is called, even if it includes end padding. This includes when the second argument is `(arg2 & 1) == 1`, where they'll return the size from the struct field it's pointing at to the end of the struct (which I whole-heartedly despise and think is a major bug, but I'm in the minority). https://github.com/llvm/llvm-project/pull/111015 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
