[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