From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 7147 invoked from network); 6 Jul 2023 16:33:19 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 6 Jul 2023 16:33:19 -0000
Received: (qmail 21911 invoked by uid 550); 6 Jul 2023 16:33:16 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 21824 invoked from network); 6 Jul 2023 16:33:15 -0000
Date: Thu, 6 Jul 2023 18:26:46 +0200
From: Szabolcs Nagy <nsz@port70.net>
To: Alex Xu <alex_y_xu@yahoo.ca>
Cc: musl@lists.openwall.com
Message-ID: <20230706162646.GG3630668@port70.net>
Mail-Followup-To: Alex Xu <alex_y_xu@yahoo.ca>, musl@lists.openwall.com
References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com>
 <168864586814.64499.13397704850676744237@alexps.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <168864586814.64499.13397704850676744237@alexps.local>
Subject: Re: [musl] __MUSL__ macro

* Alex Xu <alex_y_xu@yahoo.ca> [2023-07-06 08:17:48 -0400]:

> Quoting Alastair Houghton (2023-07-06 06:48:04)
> > Hi all,
> >=20
> > Before I start, I=E2=80=99m aware of
> >=20
> >   <https://www.openwall.com/lists/musl/2013/03/29/13>
> >=20
> > but I *still* want to add __MUSL__ (see attached patch).
> >=20
> > Let me explain what we=E2=80=99re doing, why we want it and why we thin=
k musl *should* have it.  We=E2=80=99re trying to add support for musl to S=
wift <https://swift.org <https://swiftlang.org/>> and its attendant core li=
braries, and there are a number of things about musl that presently differ =
=66rom other platforms/C libraries we support.
>=20
> All of these seem to fall at least suspiciously closely to "the usage
> case was badly wrong"...

the problem is not that the usage is wrong, but that
these can change between different versions of musl
(within abi constraints) and header changes can be
backported by distros.

so __MUSL__ cannot solve these issues.