From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6FA813858CDA for ; Thu, 30 Mar 2023 14:44:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FA813858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680187480; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wn25T9ASuPNeWbaDNVf/82L00HRXUIe8KetusepBMeE=; b=N0dH3a9YHrwKiD3fXMEUyNOPzz9HDc+BGyFcFIztp2SzCYhb47+Wt8AbVPQ2tru8zmutet j8Em8Di4Moa1LdwzQIMFgfonLAG4mMEEi4bGp114P9WHIBg+cccDqReMLlkDRbC1QQBxZm g54HBeGX60Zdp1rQIiBSPWb+5JB+fLs= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-DWHOTVuQPMeOlyfpsvZIgQ-1; Thu, 30 Mar 2023 10:44:38 -0400 X-MC-Unique: DWHOTVuQPMeOlyfpsvZIgQ-1 Received: by mail-lj1-f198.google.com with SMTP id r26-20020a2e8e3a000000b00299cd6d82ddso4253406ljk.7 for ; Thu, 30 Mar 2023 07:44:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680187477; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wn25T9ASuPNeWbaDNVf/82L00HRXUIe8KetusepBMeE=; b=d3P3TE64SeoOT837EQbqCkDfNZpQ81V0k0sh8973Cv7QkVq3GIvDOF/qIIYs0bf5p6 6zYLxmzDEdUzR6Tt0kqlw+mnZRNHwVNt6MbcEfaIBkyZpO27ZyD4QUiED1LgXvpTQlVF ID+dZ6B/DMzzCIJQBM+h6LpynBbf2hXI7FhfvigaOgWSEHRdO3v5FrlQMQNIpj7eOmqR 7i76VpqePlv5ngFCnPbEkI8u9qaPllf0YU8iJ5GHHO3PCYFkz6aNw6d2GWzhQ1USeyOW OnlVvQQTxgZYiPqoU/Hg9O0F6YrtK5Z7jCQV2x7zb/xa3FTDdcNBOghTZjBdyFysQk6E +Z2w== X-Gm-Message-State: AAQBX9fmviy2VX3+aUPnMfUzDFmkxTXxqLxI4EfQqoUHCj0MXqt9pI7G FTjsP6pGyk6lTASRNfRvyhV982Ch7j9OrL3KcloYjmylwdw/PO9O3gsYYzRMdQaKnQvyYi88RUF B9WHTDu6iT/LMG9EptXHtn5WitrztjMgfToYsr1mCll2u X-Received: by 2002:ac2:514e:0:b0:4e8:dcb2:b2ea with SMTP id q14-20020ac2514e000000b004e8dcb2b2eamr7015054lfd.8.1680187477416; Thu, 30 Mar 2023 07:44:37 -0700 (PDT) X-Google-Smtp-Source: AKy350bDrIGGOO2galQ+TlbQB1JF9FwQSIm/diJlvDRFweiaorsB7/mYfWS34q89nVnfdnJw28y8UZ5G6rT222Lwl/s= X-Received: by 2002:ac2:514e:0:b0:4e8:dcb2:b2ea with SMTP id q14-20020ac2514e000000b004e8dcb2b2eamr7015042lfd.8.1680187476872; Thu, 30 Mar 2023 07:44:36 -0700 (PDT) MIME-Version: 1.0 References: <20230329234000.1405216-1-jwakely@redhat.com> In-Reply-To: <20230329234000.1405216-1-jwakely@redhat.com> From: Jonathan Wakely Date: Thu, 30 Mar 2023 15:44:25 +0100 Message-ID: Subject: Re: [committed] libstdc++: Fix constexpr functions in To: libstdc++@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 30 Mar 2023 at 00:40, Jonathan Wakely via Libstdc++ wrote: > > Tested powerpc64le-linux. Pushed to trunk. > > -- >8 -- > > Change ip::basic_endpoint to work in constant expressions, but only for > C++20 and later (due to the use of a union, which cannot change active > member in constexpr evaluation until C++20). > > During constant evaluation we cannot inspect the common initial sequence > of basic_endpoint's union members to check whether sin_family == AF_INET > or AF_INET6. This means we need to store an additional boolean member > that remembers whether we have a v4 or v6 address. The address type can > change behind our backs if a user copies an address to the data() > pointer and then calls resize(n), so we need to inspect the sa_family_t > member in the union after a resize and update the boolean. POSIX only > guarantees that the sa_family_t member of each protocol-specific address > structure is at the same offset and of the same type, not that there is > a common initial sequence. The check in resize is done using memcmp, so > that we avoid accessing an inactive member of the union if the > sockaddr_in and sockaddr_in6 structures do not have a common initial > sequence that includes the sa_family_t member. If we had https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2641r2.html then we wouldn't need the extra boolean. During constant evaluation we could use the new magic function to check which union member is active, and during runtime we could inspect the sa_family_t member (still using memcmp, because POSIX doesn't guarantee a common initial sequence, even though I think everybody does give it one in practice).