[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Jul 2023 11:24:51 -0400
From: Andrew Bell <andrew.bell.ia@...il.com>
To: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
On Fri, Jul 7, 2023 at 11:20 AM Markus Wichmann <nullplan@....net> wrote:
> Am Fri, Jul 07, 2023 at 11:02:21AM -0400 schrieb Andrew Bell:
> > I guess I don't understand the opposition -- is there any downside to
> musl
> > to having the macros defined, necessary or not? (I'm saying this as a
> > minimalist, so I'm surprising myself here.)
> >
>
> Yes, it makes people write worse code. Not making the macros available
> makes people write more portable code, which is a good thing. Sometimes
> people have to be made to think for a moment, and broken out of their
> rut, to get them to do the right thing.
>
I guess I just don't think this is the job of a library -- to be the
arbiter of other people's programming. I may have seen some code inside
musl that I personally don't like ;)
> There is also the issue of what exactly the macros mean. Between
> distribution patches and backports, a version number does not
> necessarily map to a feature or bug set. And musl does not want to have
> any quirks, it wants to just be a POSIX implementation. So what
> specialties are supposed to be kept in mind when the musl macro is
> defined?
I understand if it can't be done well, but I would hope that it's not a big
deal to do. I do appreciate the adherence to standards and it seems
perfectly fine to respond to questions/proposals with "that's not the way
the standard works." But if this is easy, I just don't see the downside
from the standpoint of maintaining musl.
--
Andrew Bell
andrew.bell.ia@...il.com
Content of type "text/html" skipped
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.
