From patchwork Fri Feb 10 16:26:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Pluzhnikov X-Patchwork-Id: 64679 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E41CB385840D for ; Fri, 10 Feb 2023 16:27:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E41CB385840D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676046459; bh=QA2H0WtyrqB2nVZlNj3wtJ6jc+mIVNSJSCeJOzcHFgs=; h=Date:Subject:To:Cc:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=VKRf7lIF5np5kxofovcQpDgFhjW74Ij9OExvk2W20OAi/A4U8gFgzJZ88W3FIRY2j 6NisbUdMjTyAqHVSyErVETGDOeCm1V9rM4ByenHWscfvQFjfQgI0KUHwS7zx0mCjIC Jv+cD5u2ff121TouzDMij/1hNzanP1oxfYPcdQiE= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by sourceware.org (Postfix) with ESMTPS id 173A83858C5F for ; Fri, 10 Feb 2023 16:27:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 173A83858C5F Received: by mail-pf1-x44a.google.com with SMTP id u3-20020a056a00124300b0056d4ab0c7cbso2869144pfi.7 for ; Fri, 10 Feb 2023 08:27:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QA2H0WtyrqB2nVZlNj3wtJ6jc+mIVNSJSCeJOzcHFgs=; b=FZJ58/ETj0ASMQDw83YG3cXWqS3fuTKWtuqpuKQOFgkAIW+izAlqMC1o8f6omLGlwV RIPW2IhO3awocalDzPypqCeYzdULCQ/u2zJZhP5SAMh12799yxEbpJgsSHpKssJX0Wpy jzZQL2nRdh1laEpltnZhrMfq8FauTjNNq4yJsFxheFqvjZwxhsToyrDQ21YS/JfxUazq ybWT/CfsK49eR29vsr6yDPRe/EPr4rxY8fCiWmjGTjDdsoqumJfFhbFwtwx5Y8EGQAcM eiqskvMcsE+rmHfGZG3zHg6ChdVDeiD2/qmbWtPn2/K/zrSU9GyhK8AEq2ixvE/Mn1WK ugtQ== X-Gm-Message-State: AO0yUKVUJyGdrHNDKvKX/RJzrBju8GGtqF5k0CNVmQN6yyadgaAxCziD CRR9QZfpvduvjj5S0cVAZ9RYmWUsRlQ+YJSx/IPX00TxPmYl+FAnS9C9foNS+P1TJrGW+Q/9KTF t7guAZ7VNnYNEaCvHzkoeBr+8CAHYmM9b6I0r4gqTzzWtWyyf0+3G/OYADBOznRFzA91l0XF59S CkZdg= X-Google-Smtp-Source: AK7set/fTjabg1Ep6oMEarcMhRTWrQMCHtoW8Oi93UWabcZGbNtSy2BAw4Jixp9TULNNsQzYE0cBHcp0YjUV9WXjtQ== X-Received: from elbrus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:12e9]) (user=ppluzhnikov job=sendgmr) by 2002:a17:902:8693:b0:197:90f8:f36 with SMTP id g19-20020a170902869300b0019790f80f36mr4017146plo.9.1676046436055; Fri, 10 Feb 2023 08:27:16 -0800 (PST) Date: Fri, 10 Feb 2023 16:26:28 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.581.gbfd45094c4-goog Message-ID: <20230210162626.3097660-1-ppluzhnikov@google.com> Subject: [committed][PATCH] Use __builtin_FILE instead of __FILE__ in assert in C++. To: libc-alpha@sourceware.org Cc: Paul Pluzhnikov X-Spam-Status: No, score=-19.7 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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-Patchwork-Original-From: Paul Pluzhnikov via Libc-alpha From: Paul Pluzhnikov Reply-To: Paul Pluzhnikov Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Likewise use __builtin_LINE instead of __LINE__. When building C++, inline functions are required to have the exact same sequence of tokens in every translation unit. But __FILE__ token, when used in a header file, does not necessarily expand to the exact same string literal, and that may cause compilation failure when C++ modules are being used. (It would also cause unpredictable output on assertion failure at runtime, but this rarely matters in practice.) For example, given the following sources: // a.h #include inline void fn () { assert (0); } // a.cc #include "a.h" // b.cc #include "foo/../a.h" preprocessing a.cc will yield a call to __assert_fail("0", "a.h", ...) but b.cc will yield __assert_fail("0", "foo/../a.h", ...) --- assert/assert.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/assert/assert.h b/assert/assert.h index 72209bc5e7..63197b819c 100644 --- a/assert/assert.h +++ b/assert/assert.h @@ -86,10 +86,21 @@ __END_DECLS parentheses around EXPR. Otherwise, those added parentheses would suppress warnings we'd expect to be detected by gcc's -Wparentheses. */ # if defined __cplusplus +# if defined __has_builtin +# if __has_builtin (__builtin_FILE) +# define __ASSERT_FILE __builtin_FILE () +# define __ASSERT_LINE __builtin_LINE () +# endif +# endif +# if !defined(__ASSERT_FILE) +# define __ASSERT_FILE __FILE__ +# define __ASSERT_LINE __LINE__ +# endif # define assert(expr) \ (static_cast (expr) \ ? void (0) \ - : __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION)) + : __assert_fail (#expr, __ASSERT_FILE, __ASSERT_LINE, \ + __ASSERT_FUNCTION)) # elif !defined __GNUC__ || defined __STRICT_ANSI__ # define assert(expr) \ ((expr) \