Wrong __assert_fail(signed/unsigned) prototype

Wrong __assert_fail(signed/unsigned) prototype

[Леонид Юрьев]

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.

Regards,
Leonid.

Re: Wrong __assert_fail(signed/unsigned) prototype

[Rich Felker]

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