From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14855 invoked from network); 27 Feb 2023 22:27:11 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 Feb 2023 22:27:11 -0000 Received: (qmail 9931 invoked by uid 550); 27 Feb 2023 22:27:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9887 invoked from network); 27 Feb 2023 22:27:06 -0000 Date: Mon, 27 Feb 2023 23:26:53 +0100 From: Szabolcs Nagy To: Fangrui Song Cc: musl@lists.openwall.com Message-ID: <20230227222653.GI726682@port70.net> Mail-Followup-To: Fangrui Song , musl@lists.openwall.com References: <20230218013333.844224-1-i@maskray.me> <20230218020320.GA4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] [PATCH] Use __builtin_FILE/__builtin_LINE if available * Fangrui Song [2023-02-21 11:09:14 -0800]: > On Sat, Feb 18, 2023 at 4:17 AM Jon Chesterfield > wrote: > > > > On Sat, 18 Feb 2023, 02:54 Fangrui Song, wrote: > > > > On Fri, Feb 17, 2023 at 6:03 PM Rich Felker wrote: > > > > > > On Fri, Feb 17, 2023 at 05:33:33PM -0800, Fangrui Song wrote: > > > > C++ inline functions are requred to have exact same sequence of tokens > > > > in every translation unit, but __FILE__ and __LINE__ may expand to > > > > different tokens. The ODR violatioin is usually benign, but it can lead > > > > to errors when C++20 modules are used. > > > > > > > > It is sad that C++ modules broke 'assert' but not surprising. Modules were largely created out of aversion to macros. This isn't something libc can fix though, I suggest a defect report against C++ instead. > > > > Changing the semantics of assert in C seems like a bad thing to do. > > > > Thanks > > I disagree. This is a footgun where the right fix (or workaround, if > you prefer) is on the libc side. It is fairly reasonable for a header > to use assert and not expect two includes using different paths to not > cause C++ module problems. > > The current module behavior regarding macros is a reasonable > compromise. It can be evolved (e.g. > https://gracicot.github.io/modules/2018/05/14/modules-macro.html). i dont see how that solves the fundamental problem: the *behavior* of assert changes depending on which include path is used and thus inline functions that are supposed to be equivalent aren't. (__builtin_FILE makes the pp-token sequence the same across the instances, but the actual code will have different paths, which while not an odr violation per the literal words of the spec, it clearly violates the reason the rule is there in the first place.) libc can avoid printing the file path in the assert fail message for c++. this makes assert less useful but it solves the conformance issue. if c++ does not specify which path assert should print (or allow it to be unpredictable) then it is difficult to do better than this. it would have been more useful to have a __builtin_canonical_FILE() or similar that gives a path that is somehow independent of include path, but we don't have that now.