[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
