[PATCH] D148381: [WIP][Clang] Add element_count attribute

Bill Wendling via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Apr 17 14:34:00 PDT 2023


void added inline comments.


================
Comment at: clang/lib/CodeGen/CGExpr.cpp:951-952
+    if (auto *ME = dyn_cast<MemberExpr>(CE->getSubExpr())) {
+      if (ME->isFlexibleArrayMemberLike(CGF.getContext(),
+                                        StrictFlexArraysLevel, true)) {
+        if (auto *MD = dyn_cast<FieldDecl>(ME->getMemberDecl())) {
----------------
nickdesaulniers wrote:
> void wrote:
> > nickdesaulniers wrote:
> > > eventually, we may want to support non-FAMs:
> > > 
> > > ```
> > > struct foo {
> > >   size_t count;
> > >   char arr [PATH_MAX] __attribute((element_count("count")));
> > > };
> > > 
> > > char *foo (size_t offset) {
> > >   struct foo my_foo = {
> > >     .count = sizeof("hello"),
> > >     .arr = "hello",
> > >   };
> > >   return &my_foo.arr[offset];
> > > }
> > > ```
> > Maybe? Though this attribute is really only for the sanitizer, which could all ready use `PATH_MAX` to ensure that it doesn't overrun the array.
> Note that `my_foo.arr` is not fully initialized; a value > sizeof("hello") and < PATH_MAX will access uninitialized memory. I think this pattern is very common in C code (use excessive stack allocation partially initialized rather than heap).
I understand that it could be useful, though as far as uninitialized memory defaulting to zero-initialized stack variables is probably the best defense. :-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148381/new/

https://reviews.llvm.org/D148381



More information about the cfe-commits mailing list