From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12629 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 22:06:19 +0100 Message-ID: <20180315210619.wvx2ctu5cgsnxxii@voyager> References: <20180315183939.GI1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1521147877 2470 195.159.176.226 (15 Mar 2018 21:04:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 21:04:37 +0000 (UTC) User-Agent: NeoMutt/20170609 (1.8.3) To: musl@lists.openwall.com Original-X-From: musl-return-12643-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 22:04:32 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ewa36-0000YX-NV for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 22:04:32 +0100 Original-Received: (qmail 9637 invoked by uid 550); 15 Mar 2018 21:06:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9613 invoked from network); 15 Mar 2018 21:06:35 -0000 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K0:f1hdYj1Nm68933wHwKspqQo4kOtlOTR/nFgumG3qZLkAjBOBsSp 7RMqT6unb58r0ZmYZQd5ASRTG4P4S0w9oaSsHR/NAcpbgbu3s14LpI0MoWHeL061MOuEE80 6i6jzmFezbprIqnt1e2Tdbvr44GW1LMrJqeE5g77UIhbiRqErjAxS4JnZnnuUmGxyIwarfE Si/wBrQZ6LXhkWqWyq+fw== X-UI-Out-Filterresults: notjunk:1;V01:K0:g+0uGaH1HX0=:ptxDXOH7nKoGRYeSaIvemO FDXL2ov42EUvQpaWOm/ALAMTA6sLErjgLLOAMTuufVXVDOsBmQC4BesdFvhO/80AJZIJW6So0 NYXaY1K1spGz2SxQvG2qdcRNaP2UIeiS4LddIUgAEidZoaXOdcLEWbf18TOPLrqpRaHGmRQC9 Lxs4YQfclHgn945BcfhjKMJUCJOC2S3pC2PgCmWvm5D0Vq/FL8fWCVVcrViHBtkQkiKDZc0O/ q9SxkFacfYJrNv7O9PaaGVwxScYLbz0IzWrw/u0pvGbpaAvKUTUKEDzHtvuTBsm3L1zPsW8Ft nTGYwgto2iFExhcULx8Fmq/YcCiDFD6b/J9//lWZZnqXA/prws4WD/bdyUK0SGlLx5hTixFsm pzxdv4YdPRjwKv8U/z01VVZ48XeJkvtQ1YkMmTrHw8EK9W0MlcGlvo8BnDsXu2sTm/+10NX0M UdfwmWj7xdY1KHOkenW+mNRBT/69TofHxcT9KHVQpZQpwW88dOiJtiMAW4oK58Qam8LM/BOUx 1xRxDIv3plYyGadYXpMgfxoTUJISEMIQRpyUuEnXWw6yn6UTTihLnH6+3NhflTX+iH8eiB/ip //RgaZ3t5+KHCF+UfZG0BGqYfEX3NHfVwdx++rPgyPWNom53wk+7Wqt+Vzx7jGPQu15jQ5O8O jR9K+d/Dhln8RFDMa0hJtVJphVvRRj+xnA8i3XXcX7AnsH06ewdrGSYenfeL3v+91MXY2iXiw TFBlGDMXaCM5qT3y3Ah292VU2uWHi9Gp6h3LPWLbR3Z2X/+07TXWqu1kd3C3uaHuOTufe2hB Xref: news.gmane.org gmane.linux.lib.musl.general:12629 Archived-At: 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