From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 127AC1F45A for ; Tue, 25 Oct 2022 20:07:16 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.b="UY4KsJMz"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onQBg-0007Ul-EQ; Tue, 25 Oct 2022 16:06:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onQBc-0007R6-UC for bug-gnulib@gnu.org; Tue, 25 Oct 2022 16:06:10 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onQBY-0001S3-6T for bug-gnulib@gnu.org; Tue, 25 Oct 2022 16:06:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1666728348; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=uxcKqDs3aPvnnbclLx75dOHIER7o/NIJQDn8C9uf97A=; b=UY4KsJMzDgOs8W7X9SL5H6HL43eyu3oXsqovdEloJSmanW9bPOjllhkYR1fin94TxX tnKQKVRfVgPaFAkgnim7AE6jpuohS6JZaZcszL/UlbQoN7Oj1E0iWQHeSxJxV+gTdNFF aEQZkfFwOaCgjY8LXn3ZJkQcQeQawtwAJhA3IAkYL+OitP3+oetVcfD0+V0JJN2ji2RK lmE7qx0w9OtdAGiQBGCKYus2ifwU4iNMGsX5bTFSEoywxH09D1rmaNWSvxYXPXzRhn/K 9z+H0w3EEgFEh2F5ks9Y4KQ2fWW2ZJawGib4xivMpwAAYVNxo31mKx4lDHsFVkk5ZqJN grjA== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPD1fMxyu++nCkLWGFLyUVNPawepQ==" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6y9PK5mAUw (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 25 Oct 2022 22:05:48 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org, Paul Eggert Subject: Re: assert-h: Make static_assert work on Solaris 11.4 Date: Tue, 25 Oct 2022 22:05:47 +0200 Message-ID: <1724411.Ii9rTq9gLj@nimes> In-Reply-To: References: <34013532.ATrlOLLGV9@nimes> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Received-SPF: none client-ip=85.215.255.25; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "bug-gnulib" Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Paul Eggert asked: > > #include > > #undef/**/assert > > + /* Solaris 11.4 defines static_assert as a macro with 2 ar= guments. > > + We need it also to be invocable with a single argument. */ > > + #if defined __sun && (__STDC_VERSION__ - 0 >=3D 201112L) && !defined = __cplusplus > > + #undef static_assert > > + #define static_assert _Static_assert > > + #endif > > #endif]) >=20 > Will this approach work if code does something like the following? I=20 > worry that the later includes would collide with config.h's=20 > definition of static_assert. >=20 > #include >=20 > #define NDEBUG 1 > #include >=20 > #define NDEBUG 0 > #include >=20 > static_assert (true); It will work. The reason is that looks like this: #ifndef _ASSERT_H #define _ASSERT_H /* Part 1: definitions that don't depend on NDEBUG */ #endif /* Part 2: definitions that depend on NDEBUG */ and the definition of 'static_assert', on Solaris 11.4, happens to be in part 1. > Come to think of it, the latest C23 draft is a little squirrelly here,=20 > as its section 7.2 says that defines a static_assert macro.=20 > This must be a typo because it never goes no to say anything about what=20 > the macro does, and static_assert is a keyword in C23. I agree. Still, 'static_assert' is _allowed_ to be a macro, by =A7 6.10.9.(= 2). > Also, while we're on the topic, why does the latest C23 draft require=20 > that when NDEBUG is defined, the assert macro is defined via "#define=20 > assert(...) ((void)0)" rather than as "#define assert(ignore)=20 > ((void)0)"? What's the point of requiring the ellipsis? I would guess that it's for compatibility for C++. ISO C++ 17 does not require anything about the argument when NDEBUG is defined. Thus, a program can contain #undef NDEBUG assert (new HashMap(3).count =3D=3D 0); and the compiler should effectively ignore this. But when the types HashMap, A, and B are not defined, the only way to ignore this line is to allow multiple arguments to 'assert' at the preprocessor level. (Because of the comma.) Most implementations get this wrong. Effectively requiring the programmer to insert extra parentheses: #undef NDEBUG assert ((new HashMap(3).count =3D=3D 0)); instead. Bruno