Date: Mon, 4 Mar 2019 09:44:58 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Wrong __assert_fail(signed/unsigned) prototype On Mon, Mar 04, 2019 at 02:15:27PM +0300, Леонид Юрьев wrote: > Hi! > > LSB 1.3...3.0 as well as ISO POSIX (2003) specifies: > void __assert_fail(const char *assertion, const char *file, unsigned > int line, const char *function); > > But now MUSL defines: > _Noreturn void __assert_fail (const char *, const char *, int, const char *); > > I.e. the problem is "int" and "unsigned int" type difference for > "line" argument. > This creates build problems if the __assert_fail() prototype is also > defined in the application source code. > > Of cause, such (re)definition of __assert_fail() is not the good > solution, but the simplest, since the __assert_fail() prototype may > not be defined. > > However, I think it's better to align __assert_fail() with POSIX and > LSB specifications. musl does not aim for any conformance to the LSB, which is essentially documentation of a particular ancient version of glibc. To be LSB-conforming, you need to be glibc or a full glibc clone (up to the functionality of that version). The LSB has been used tangentially as a reference for ABI compatibility, for providing glibc-ABI-compat, but this is purely a binary-level matter, not source-level, where the signedness of the type is not relevant. POSIX does not specify __assert_fail or any particular mechanism behind the assert macro, and declaring or calling this function manually is not supported usage. It's possible that a future version of musl would provide it only at a binary-compat level, and use some different mechanism for implementing assert.h. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.