Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250307234848.GY1827@brightrain.aerifal.cx>
Date: Fri, 7 Mar 2025 18:48:48 -0500
From: Rich Felker <dalias@...c.org>
To: Thorsten Glaser <tg@...bsd.de>
Cc: musl@...ts.openwall.com
Subject: Re: f128 aliases for long double math symbols

On Fri, Mar 07, 2025 at 08:09:28PM +0100, Thorsten Glaser wrote:
> On Fri, 7 Mar 2025, Rich Felker wrote:
> 
> >The type issue is completely separate. It's a matter of the library
> >implementation invoking UB with respect to the compiler implementation
> 
> 1. The library implementation does not need to use C.
> 2. The C standard explicitly allows the implementation itself
>    to handwave numerous things that would otherwise be UB in
>    application code, e.g. pre-C23 there was no way to write
>    strchr(3) in conforming C.

I think that agrees with what I said. The type issue is a type issue
because we demand analyzability and compatibility with type checking
tooling and, on a more abstract level, because we demand that the C in
musl be valid freestanding C that may depend on particular
implementation-defined behaviors and a small set of extensions, but
not on undefined behavior. This is a choice.

> >The issue at hand is one of the implementation not conforming to
> >requirements that applications are permitted to rely upon.
> 
> That’s explicitly allowed by the standard.
> 
> >> i dont think the standard explicitly requires unequal library
> >> functions.
> >
> >I don't see how you read that. The standard specifies two functions,
> >and specifies that different functions compare not-equal. It does not
> >rigorously define the word "different" but that's par for WG14.
> 
> It does not mandate that memcpy be different from memmove either
> (in fact Stephen found the DR stating that they may indeed be equal).

Indeed, the DR -- while garbage as written, not giving any rationale
for the answers -- settles that. I disagree with any interpretation
that it's allowed by the language of the standard as written, but as
we've seen that's often imprecise/ambiguous, and if the agreed-upon
resolution is that it's allowed, then it's allowed.

I don't think it's an allowance that I'd like to make use of, and I
don't see any clear indication that there's a general principle being
applied here rather than "oh yeah that sounds good to me".

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.