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-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, 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 C20F61F4B4 for ; Thu, 14 Jan 2021 01:22:10 +0000 (UTC) Received: from localhost ([::1]:42048 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kzrKz-00084j-Fm for normalperson@yhbt.net; Wed, 13 Jan 2021 20:22:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzrKl-00084b-4K for bug-gnulib@gnu.org; Wed, 13 Jan 2021 20:21:55 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.23]:21802) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kzrKf-0001ZV-Hw for bug-gnulib@gnu.org; Wed, 13 Jan 2021 20:21:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610587306; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:From: Subject:Sender; bh=0HUfqb5uxoMfY/mlBtitny2q3LiWsfWKKKQTn+ClKuU=; b=iFQcUn2QLK8M17/fvClkHsi8xcg6hWlfwoqeFx4FzIqDohplT6hniuQrInPUcu5mJs DdzT9fq14mbn83kGQKUnvXUDGktp8T1sB+VJ9qFJNVREky6fLxVTHRv6Gp+Jm0aYUUM6 TgG6rwBhEvpOXnwLXyDD2agDa3ajIsyQFiScIR85lJFBmCD/0ivA016POJNrJk41aQ53 Lpc5xSII9ZRC4skoZAfTCDzAyPumX98/OdpEuDrsZ2yFDTEx7FqLqA2fzEhsuuEFsu7L +RBEI+BOU10Qi/bypoUPT33u9r1su+vGg2yi/jSuMAFJPQpBaKKM6aGwE0T9OAYawABe EPfA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyvs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id u0aa20x0E1Lkb1P (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 14 Jan 2021 02:21:46 +0100 (CET) From: Bruno Haible To: Paul Eggert Subject: Re: clang++ 11 compilation issues Date: Thu, 14 Jan 2021 02:21:45 +0100 Message-ID: <4753995.LDMlyKNlAT@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-197-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1a11d0b0-36d5-cec2-c4c3-dc6003aa22d3@cs.ucla.edu> References: <87k0sixwya.fsf@lrde.epita.fr> <2634507.PNdPYx674J@omega> <1a11d0b0-36d5-cec2-c4c3-dc6003aa22d3@cs.ucla.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.23; 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, Alexandre Duret-Lutz Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Paul, > Also, looking over the current verify.h, it's a little complicated and I > doubt whether the complexity is worth it nowadays. How about if we > simplify the C++ case, by simply relying on __cpp_static_assert there? > Although this could miss opportunities for generating diagnostics via > older C++ compilers, I doubt whether they're worth the trouble any more. The risk here is not that the new code misses opportunities for generating diagnostics. The risk here is that the new code introduces compilation errors in C++ mode. Recall that in this area C and C++ are very different; which is why the code starts with a '#if[n]def __cplusplus'. If you try to handle C and C++ through the same code and conditions, it is not only possibly buggy, but also certainly unmaintainable. For example, say, someone use g++ version >= 5 with option -std=c++98. Then, with your new code, __cpp_static_assert will be undefined, _GL_HAVE__STATIC_ASSERT will be 1, and _GL_VERIFY(R, DIAGNOSTIC, ...) will expand to _Static_assert (R, DIAGNOSTIC) which most likely leads to a syntax error. Also note that the C++ test coverage of this module is currently zero (none). This means that if you make this change and it is buggy, we have no way to catch it, before some user will stumble across it. Bruno