[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Mar 2018 22:06:19 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Re: #define __MUSL__ in features.h
On Thu, Mar 15, 2018 at 03:51:22PM -0300, dgutson . wrote:
> Fact #1: Software is not perfect. Bugs may show up. And sometimes in bad
> timing when doing a release.
> So, user developers have two options: hack the library with a workaround,
> and release with a
> hacked library untested and unverified by its supporting community, or they
> can leave the library as-is, and
> implement the workaround in the using code (which requires the macro in
> order to limit the impact to the library implementation).
>
You know, you could just write your own macro, right? It doesn't have to
be __MUSL__, it could be called HAVE_BUGGY_SOMETHING, and it could be
defined in a config.h. And it is entirely up to you how it gets there.
Let's say musl had a bug in glob() somewhere. What you want to do is:
#ifdef __MUSL__
assume glob() is buggy
#else
use glob()
#endif
What Rich wants you to do is write a configure script that compiles a
program against the library, runs it and tests it output against two
alternatives. Then you can write
#ifdef HAVE_BUGGY_GLOB
assume glob() is buggy
#else
use glob()
#endif
The difference is about five minutes of work. And if you can't be
bothered to spend even those five minutes, you probably aren't going to
bother with the #ifdef stuff anyway. If it has to work HERE and NOW, you
just write the code conforming to the current situation. Might not work
tomorrow, but oh well, that's why it's called technical debt.
Oh, and if you're cross compiling, write a test program, run it on the
target, then create a config.h according to the results.
> Fact #2: Fixes take time, because community projects have their own agenda
> and triaging policies.
>
> So, in the hypothetical bug of a library (no matter this particular case I
> referred to, there were, there are, and there will always be bugs)
> the macro will work as an escape hatch until the fix of the hypothetical
> bug is ready upstream.
>
In a better world, that would be the case. In the real world, the
temporary solution is staying in place until it fails -- and it never
does. As soon as it works, you move on. Maybe the original author of the
workaround has left the company. Years later, some inquisitive soul will
ask why that #ifdef __MUSL__ strangeness is still in place, and no-one
will be able to answer, except with a cargo cult mentality. "Just let it
stay there, it doesn't hurt anything." Entire generations will grow up
reading that code and learning "musl has bug X", then move on to other
companies to spread the misinformation further. And all because you
couldn't be arsed to write a test!
I might have exaggerated a bit there.
> I'm writing this from a very practical and industry point of view (who have
> worked in FLOSS projects before and commercial projects).
>
I have worked in embedded software for four years now, and what I have
seen does not inspire confidence in the continuous improvement processes
of the industry, to put it mildly.
Ciao,
Markus
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.
