Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 4 Mar 2019 09:44:58 -0500
From: Rich Felker <>
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.


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.