Description

macro CONTAINING_RECORD in

ubsan runtime will complain about this.

The code contains what appears to be legacy idiomatic code for computing offsetof(). offsetof() was a late addition to C.

I've confirmed that for clang-14 for C and C++ programs, ubsan will not complain about what goes on underneath the covers of offsetof.

It would be nice of some compile time tool could find this; perhaps there's some flag to clang, msvcc or gcc that can sniff these out?

grepping and hand editing turns up these suspicious code smells:

./mono/mono/eglib/glib.h:#   define offsetof(s_name,n_name) (size_t)(char *)&(((s_name*)0)->m_name)
./coreclr/nativeaot/Runtime/CommonMacros.h:#define offsetof(s,m)   (uintptr_t)( (intptr_t)&reinterpret_cast<const volatile char&>((((s *)0)->m)) )
./coreclr/pal/src/include/pal/list.h:                                                  (ULONG_PTR)(&((type *)0)->field)))

The macro definitions look especialy smelly.

I do not know all of the clients of pal/list.h, nor the legacy requirements, etc, etc.

I think we should "program to the tool" rather than suppressing errors from this construct; the suppression is likely to be a blunt insrument.

Reproduction Steps

compile -fsanitize=address without suppressions and run without suppressions, and hope your test triggers runtime error

runtime error: member access within null pointer of type

Expected behavior

no runtime errors when there are no suppressions

Actual behavior

runtime errors when there are no suppressions

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response