[PATCH] D41405: Fix an assertion failure regression in isDesignatorAtObjectEnd for __builtin_object_size with incomplete array type in struct
George Burgess IV via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Dec 19 13:28:54 PST 2017
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
More information about the cfe-commits
mailing list