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.