[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