Re: [PATCH bpf-next 1/2] libbpf: add option to force-anonymize nested structs for BTF dump

[Alan Maguire <alan.maguire@oracle.com>]

On 17/12/2025 17:06, Andrii Nakryiko wrote:
> On Wed, Dec 17, 2025 at 8:13 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Wed, Dec 17, 2025 at 8:06 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>>>
>>> struct foo {
>>>         struct foo *ptr;
>>> };
>>>
>>> struct bar {
>>>
>>> #ifdef __MS_EXTENSIONS__
>>>         struct foo;
>>> #else
>>>         struct {
>>>                 struct foo *ptr;
>>>         };
>>> #endif
>>
>> Did you test it ? I suspect AI invented it.
>> I see nothing like this in gcc or llvm sources.
> 
> Grepping a bit I suspect we need to check for _MSC_EXTENSIONS, worst
> case - _MSC_VER. But Alan, please double check in practice.

Thanks; I tried these too, no luck with either gcc or clang. Looks like the
requests to merge them haven't landed yet, latest I could find on this was [1]/[2].

I guess the other approach would be to have the user explicitly #define a
macro prior to vmlinux.h inclusion if they want to use the extensions, similar 
to how we handle BPF_NO_PRESERVE_ACCESS_INDEX; maybe call it BPF_USE_MS_EXTENSIONS 
or similar? It could default to true if _MSC_EXTENSIONS is set to future-proof it.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110977
[2] https://reviews.llvm.org/D157334