From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 9E5713858D39 for ; Fri, 26 Jan 2024 14:58:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E5713858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dgtlrift.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=dgtlrift.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9E5713858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::62d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706281093; cv=none; b=hqo1DBvxicsyQxHQ+ee+Tw+tPA8TG7BFCdoYvvJmYGtEO6ZXCYxwv4HWD4xs3Lce3bWnRZokmPR0TWE/xujhwxlVLkPau+rIplT/VNywU+ORoptBqt9urH+kAe/RdeOdEz6vs1pds0TqmC/XPaRfocNvx5txy8X3E/rhRrEhTEI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706281093; c=relaxed/simple; bh=+/xUV6hKdlnH8gzxDUfr6Cp5YX3VscsYmfOXvFKDQf4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=NFnO4KKXxVh0C4x6/eJK+7XWXXK52s53EAaUQHi5qjLTroJKDEtsSHX1qUjs8uF+EBfo5Eu2Xi+Z8lwFCyx8jNnySUkOynC/XJ1pXvplm9EpaXv3AO2JkGV47ilIabE0IiQTe28aOFQ5CqgZQmNCYoQMZiNI3dGpMfZk0KWQm9U= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a27e7b70152so19562466b.0 for ; Fri, 26 Jan 2024 06:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dgtlrift-com.20230601.gappssmtp.com; s=20230601; t=1706281089; x=1706885889; darn=sourceware.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3rQmHgj3Pcwpp+oqY3xpnWJlDPNxTjfQJA51kDxevhQ=; b=xvvW0wTY8tAutxW9vp3osqlc8rVQh/m8iT++04WLSa83JPRVNzZK1KS8RE/qyA1MSr 1zwugOGFtBeO4ilRTwOYwWrt2kqIiTNpCGd+DFP7cQ/Sx8atA8rPfBvdEblGiCifHrnr pzdwpfAaYob3RaoCiuKjntEYUsxse4OzyaWwfu00odaQZP+saL7VOYU0NWMZa2VOG46C nPgNofqmPs+WiuYoVOcsVviMnID65wBGAiz1t2fouXVTggrhbAofRakcWOXWtA7DYNYd 1RzfPCDv4ccmQZJRhDjNuh1KH4i7Cod/PmlFZNHKGQ00/8iZclNXL44HQWKpT8bJIeIy IBGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706281089; x=1706885889; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3rQmHgj3Pcwpp+oqY3xpnWJlDPNxTjfQJA51kDxevhQ=; b=VBzCt8/kvnNkJgwn0r0gFjHMv3EdwK+Eo87gg0dbIzp8QdWnHSxCZwv3qj/812fTz/ 66SA+BRyRa4pK39mpC3BzsnozK23kfZ8yMlFwi5AIfut5TlmU2SfY0CDBuYCH1NCyYYZ YUYTkUj/+8V7lOialnRkEASr1vOYir+Pvusc/iLGrAv8wKZLosD64J3pKxgnSk0+P88t pjttbbWClGJLUa0SQxOffZLQ/vKXhQ7wOzaFnszUt6LCWzrrEZgQ8Qy04i8ijz4cHWx8 D20MTQj9X5NikAHXHoKKPVXcnVJXK0GEmsgY2W/nuOM2muLGdolVAJaRCnud3G9N478Y MPAQ== X-Gm-Message-State: AOJu0YwINA4QgE942io4oe2vFws0tfIeHXtncWmL2wPamrpfsz8tIWro ryqVNq/50w1qZ1Csea6JOZGdY6ccjalWg3Lhk6kY4qzENpybYprtG8vJCezelnL5PIfUGy9xDkE NQGGwe3fj2A5qOZIXvDF1s1LZf5BFQFms50p1D87uoUxLsNhMpA== X-Google-Smtp-Source: AGHT+IFpT/Qv3q0pVue3d6aQnqujzERGNxe3vANn0JUroV5jKaZB10x2DUELjQAbr5TylossyEINOs+O8QOGin1C0ZU= X-Received: by 2002:a17:906:1d0f:b0:a34:d7db:1ae4 with SMTP id n15-20020a1709061d0f00b00a34d7db1ae4mr1019677ejh.2.1706281088975; Fri, 26 Jan 2024 06:58:08 -0800 (PST) MIME-Version: 1.0 From: James Hanley Date: Fri, 26 Jan 2024 09:57:57 -0500 Message-ID: Subject: in6_addr struct union with uint64_t To: libc-alpha@sourceware.org Content-Type: multipart/alternative; boundary="000000000000321924060fda8652" X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000321924060fda8652 Content-Type: text/plain; charset="UTF-8" In a local experiment, I added the union fields __u6_addr64 and __u6_addr128 for in the in6_addr structure to allow the compiler to optimize access for the Interface ID of an IPv6 address as applicable using the EUI-48/64 in IPv6 in the case of the uint64_t and to allow the compiler to optimize access when comparing, setting, manipulating IPv6 addresses as a whole with the GCC specific unsigned __int128. Code below modified from inet/netinet/in.h: #if !__USE_KERNEL_IPV6_DEFS /* IPv6 address */ struct in6_addr { union { uint8_t __u6_addr8[16]; uint16_t __u6_addr16[8]; uint32_t __u6_addr32[4]; uint64_t __u6_addr64[2]; // new unsigned __int128 __u6_addr128; // new } __in6_u; #define s6_addr __in6_u.__u6_addr8 #ifdef __USE_MISC # define s6_addr16 __in6_u.__u6_addr16 # define s6_addr32 __in6_u.__u6_addr32 # define s6_addr64 __in6_u.__u6_addr64 # define s6_addr128 __in6_u.__u6_addr128 #endif }; #endif /* !__USE_KERNEL_IPV6_DEFS */ First, is this useful, and is there a standard that prohibits defining additional union members? Second, when building, I hit an alignment issue in an assertion check in resolv/resolv_conf.c comparing sockaddr_in and sockaddr_in6 with the change. I assumed I should add "__attribute__((aligned(128)))" ahead of the struct sockaddr_in definition to force sockaddr_in to align to 128bit, however, this did not resolve the issue. Any suggestions? Thanks much, -Jim --000000000000321924060fda8652--