Re: [musl] __MUSL__ macro

[Andrew Bell <andrew.bell.ia@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Fri, Jul 7, 2023 at 11:20 AM Markus Wichmann <nullplan@gmx.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@gmail.com

[-- Attachment #2: Type: text/html, Size: 2266 bytes --]