[all-commits] [llvm/llvm-project] 05d152: [libc] Add definition of struct in6_addr to netine...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 05d152bd59372aa3e10bbf06deae5795a81052d9
      https://github.com/llvm/llvm-project/commit/05d152bd59372aa3e10bbf06deae5795a81052d9
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2026-06-02 (Tue, 02 Jun 2026)

  Changed paths:
    M libc/hdr/types/CMakeLists.txt
    A libc/hdr/types/struct_in6_addr.h
    M libc/include/CMakeLists.txt
    M libc/include/llvm-libc-types/CMakeLists.txt
    A libc/include/llvm-libc-types/struct_in6_addr.h
    M libc/include/netinet/in.yaml
    M libc/test/src/netinet/CMakeLists.txt
    A libc/test/src/netinet/in_test.cpp

  Log Message:
  -----------
  [libc] Add definition of struct in6_addr to netinet/in.h (#201057)

This patch implements the struct in6_addr definition for netinet/in.h,
mapping it from netinet/in.yaml to the generated public header.

I've defined struct in6_addr under include/llvm-libc-types/ using an
anonymous union containing s6_addr, s6_addr16, and s6_addr32 (only the
first one is mandated by POSIX). Other implementations achieve this by
using a named union and defining the members as macros. This approach is
cleaner, but could potentially run into compatibility problems with code
which expects s6_addr is a macro. If we do, we may have to re-evaluate
this approach, but I'd like to avoid uglyfying this preemptively.

I added a simple test to check the memory layout of the address.

Assisted by Gemini.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications