On 2025-04-10 01:41, Martin Uecker wrote:
I have some questions about this: The access would add new reads to the size field. For counted_by, so far, those are somehow coupled to the access to the member. From this you would assume
For the currently implemented subset, updates to the storage of the annotated FAM and updates to its counted_by size need to be coupled to prevent reordering because their relationship is otherwise implicit.
This proposed feature would need the counted_by size and the containing struct of the FAM to be coupled to make that relationship explicit, but it's not necessarily to prevent reordering because this case needs to only be considered when the update of the storage for the struct (or its containing FAM) is not visible. That is, the pointer either comes in as a parameter or a non-allocator call returning that pointer.
Now it is entirely possible that further inlining gets the allocator in and it would be possible to thread through the .ACCESS_WITH_SIZE to reach the allocator, but I would argue that the counted_by + size of struct should be the canonical result.
that inserting the new accesses to the size field are ok (e.g. one can assume the struct is accessible, there are no new race conditions under some assumptions, it is initialized). If you now want to read the size at different points, all this is even less clear to me.
I'm not sure about race conditions, the coupling was to prevent reordering. Would you be able to elaborate on the race condition question?
I may miss something, but I think one would have to first define a clear criterion when it is ok to access the size field.
This is a contentious issue I had not thought of; if the pointer ends up being NULL at runtime, a dereference due to the size expression for the containing struct will end up validating it for subsequent passes, which may makes things even worse. The size expression will also need a NULL check to work around this.
So to me it seems we can not simply insert it at specific point in the C FE where a pointer to the struct is used, but only when there is some specific trigger. An example I could imagine is when you memcpy the struct. (but it is also not entirely clear why this should not be allowed to go beyond the counted_by size if the underlying storage is larger).
IMO, I don't think underallocation/overallocation (and expecting the additional allocation to be usable) and counted_by for FAM should be allowed to coexist. That's just a source for confusion.
Maybe you could add it when a pointer to an annotated struct is passed as parameter, but also there it is not clear to me that we might want to materialize new accesses to the struct at this point. An alternative approach could be to just do it when such a pointer is explicitely passed to the BDOS builtin.
I suppose bounds sanitizer won't be affected by this but wouldn't this then exclude the object-size sanitizer? I don't know if its instrumentation runs early enough.
Thanks, Sid
