From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id B8C1A3857C69 for ; Mon, 21 Sep 2020 10:11:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B8C1A3857C69 Received: by mail-wm1-x32c.google.com with SMTP id k18so11987322wmj.5; Mon, 21 Sep 2020 03:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s7ii2uvkfzB+oSYuCdJH5GN6IdXgJMjSAIykPCmDKtw=; b=Ea/HjCGGLEDHk09BmZ2YiUgdnIY/sG8Izy9D4/1kKQrJAkheYcQkYh+tjzrx7qPZI8 TzwaDX+rpJtkHIZVgZnA3GBd6AgVt0imVrdMy4YPvjG8fjuzCydkZtlMtC7IaK3DF5Ru q1ExJYkyGm91dL8kzrvRyQu5xUKkhPVykSZw1RWm1qa1QCMDtvO+raMXNI78B4ozQXpg 1mwZ165Bfz9VftpdvQuzuaRWqrz8Vb68ccIjg0UOVRgZQtJBm7vfDCwRdT7/9bS+YKYd aIwuBqZszGEXt3xo3CJZXLPQCVQ+q410/9yl2IVrIDEEX5wKeZoGziThpjdbgc7or06h Illw== X-Gm-Message-State: AOAM5304SKkgf54bTwSrPGEYlIqZ2p/oUK3VyT+K7fsPXxXhv+srw1Um iuvve7VPU3WQiSWaqBdI/1WFTu64RM4= X-Google-Smtp-Source: ABdhPJzogvRZjgPisuXNjNYWPDxDWo7Fd2BGwUQwegw/aCyLzQHz7/5AULqwlxhtKV6MCTQrp2VyRQ== X-Received: by 2002:a7b:c847:: with SMTP id c7mr29914739wml.149.1600683104835; Mon, 21 Sep 2020 03:11:44 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id l16sm21507676wrb.70.2020.09.21.03.11.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 03:11:44 -0700 (PDT) Subject: Re: Expose 'array_length()' macro in or To: Florian Weimer References: <946e9377-0558-3adf-3eb9-38c507afe2d0@gmail.com> <874knr8qyl.fsf@oldenburg2.str.redhat.com> From: Alejandro Colomar Cc: Libc-alpha , libc-coord@sourceware.org, gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Message-ID: Date: Mon, 21 Sep 2020 12:11:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <874knr8qyl.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 10:11:47 -0000 [[ CC += libc-coord@sourceware.org CC += gcc@gcc.gnu.org CC += libstdc++@gcc.gnu.org ]] Hi Florian, On 2020-09-21 10:38, Florian Weimer wrote: > * Alejandro Colomar via Libc-alpha: > >> I'd like to propose exposing the macro 'array_length()' as defined in >> 'include/array_length.h' to the user. > > It would need a good C++ port, probably one for C++98 and another one > for C++14 or later. For C++, I use the following definition: #include #include #include #define is_array__(a) (std::is_array <__typeof__(a)>::value) #define must_be_array(arr) \ static_assert(is_array__(arr), "Must be an array !") #define array_length(arr) ( \ { \ must_be_array(arr); \ __arraycount((arr)); \ } \ ) This solves the problem about G++ not having __builtin_types_compatible_p(). However, there are a few problems: 1) This doesn't work for VLAs (GNU extension). I couldn't find a way to do it. Maybe I should file a bug in GCC. 2) Also, this requires C++11; I don't know how to do it for older C++. Again, support from the compiler would be great. 3) The macro can't be used in the same places as the C version, because of the `({})`. The `0 * sizeof(struct{...})` trick doesn't work in C++ due to: error: types may not be defined in 'sizeof' expressions > >> Libbsd provides '__arraycount()' in and some BSDs provide >> 'nitems()' in , so any of those 2 headers may be a good >> place to do it. > > In this case, I would prefer nitems in , given that there > is precedent for it. seems to be a bit drastic for a new > macro with such a common name; it would create widespread build > breakage. Ok. I guess you would use 'nitems()' name, right? > > Maybe also ask on the libc-coord list. Ok. Added CCs. > > Thanks, > Florian > Thanks, Alex