george.burgess.iv accepted this revision.
george.burgess.iv added a comment.
This revision is now accepted and ready to land.
LGTM assuming my nit gets addressed.
Thank you!
> Maybe someone who's more familiar with this builtin could point to the cause
> of this discrepancy
Yeah, the documentation for this builtin is pretty sparse. My guess: clang
assumes that the array's size is unknown because it's both an array and at the
end of a struct. This exists because code will do clever things like
struct string {
size_t len;
char buf[1]; // actual string is accessed from here; `string` just gets
overallocated to hold it all.
};
in FreeBSD-land, they also recommend overallocation with sockaddrs, which have
a 14-length trailing element:
https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html
...So, the best compatible heuristic we've been able to settle on here, sadly,
is "are we touching the final element in a struct, and is that element an
array?" On the bright side, clang failing just means LLVM gets to try to figure
it out, so only some hope of getting a useful answer is lost. :)
It's interesting that GCC tries to do better here, since AIUI it has a similar
heuristic meant to cope with code like the above.
================
Comment at: test/Sema/builtin-object-size.c:95
+
+typedef struct {
+ char string[512];
----------------
Please clang-format the additions to this file.
Repository:
rC Clang
https://reviews.llvm.org/D41405
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
