Am Mittwoch, dem 25.10.2023 um 15:32 -0700 schrieb Kees Cook: > On Wed, Oct 25, 2023 at 10:27:41PM +0000, Qing Zhao wrote: > > > > > > > On Oct 25, 2023, at 6:06 PM, Kees Cook <keesc...@chromium.org> wrote: > > > > > > On Wed, Oct 25, 2023 at 01:27:29PM +0000, Qing Zhao wrote: > > > > A. Add an additional argument, the size parameter, to __bdos, > > > > A.1, during FE; > > > > A.2, during gimplification phase; > > > > > > I just wanted to clarify that this is all just an "internal" detail, > > > yes? > > > > YES! > > Okay, I thought so, but I just wanted to double-check. :) > > > > For example, the Linux kernel can still use __bdos() without knowing > > > the count member ahead of time (otherwise it kind of defeats the purpose). > > Don’t quite understand this, could you clarify? > > I was just trying to explain why a chance would be a problem. But it > doesn't matter, so nevermind. :) > > > (Anyway, the bottom line is no change to the user interface, we just > > discuss the internal implementation inside GCC) -:) > > Great! I'll go back to lurking. :) > > Thanks! >
While it is about the internal implementation, it would potentially affect the semantics of the attribute: This would work: x->count = 10; char *p = &x->buf; but not this: char *p = &x->buf; x->count = 1; p[10] = 1; // ! (because the pointer is passed around the store to the counter) and also here the second store is then irrelevant for the access: x->count = 10; char* p = &x->buf; ... x->count = 1; // somewhere else ---- p[9] = 1; // ok, because count matter when buf was accesssed. IMHO this makes sense also from the user side and are the desirable semantics we discussed before. But can you take a look at this? This should simulate it fairly well: https://godbolt.org/z/xq89aM7Gr (the call to the noinline function would go away, but not necessarily its impact on optimization) Martin
