From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2541 Path: news.gmane.org!not-for-mail From: croco@openwall.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: NULL Date: Wed, 9 Jan 2013 18:49:25 +0400 Message-ID: <20130109144925.GB2947@openwall.com> References: <50ED4E45.6050801@barfooze.de> <20130109130927.GA2947@openwall.com> <50ED74FE.9030306@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1357742977 14392 80.91.229.3 (9 Jan 2013 14:49:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2013 14:49:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2542-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 09 15:49:53 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TswyW-0002Cu-Mq for gllmg-musl@plane.gmane.org; Wed, 09 Jan 2013 15:49:52 +0100 Original-Received: (qmail 20392 invoked by uid 550); 9 Jan 2013 14:49:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20384 invoked from network); 9 Jan 2013 14:49:36 -0000 Content-Disposition: inline In-Reply-To: <50ED74FE.9030306@barfooze.de> User-Agent: Mutt/1.5.18 (2008-05-17) Xref: news.gmane.org gmane.linux.lib.musl.general:2541 Archived-At: On Wed, Jan 09, 2013 at 02:47:42PM +0100, John Spencer wrote: >> choosen, despite we don't like it. However, I'd suggest at least to let >> the people know this is a WORKAROUND for the bugs THEY introduce: make this >> hack disabled by default, enabled by a compile-time option, and issue a >> warning which points them to this discussion or something similar. > > as of now, musl only supports a single configuration. > having 2 different versions of musl in the wild, one that works with > their apps and another one that does not, is definitely not desirable Well, the matter we discuss here doesn't affect the compiled code of musl, does it? And the header can have these #idfef's so that people have to compile their _buggy_ apps using smth. like -DMUSL_CPLUSPLUS_NULL_WORKAROUND=1 If I'm wrong and miss something (so that my suggestion requires to maintain separate musl binaries), then... heh... Well, then I'd vote against such a workaround (for the reasons I already mentioned about the more and more people who doesn't want to learn), but my opinion shouldn't perhaps cost much as I'm not a musl developer. >> Something like "Okay, if your program doesn't work without this workaround, >> then you can use the workaround, but you'd better fix your program". This >> will not do much influence while musl is not so popular, but I hope it will >> become popular one day (I really do... let's give the damn world a chance), >> and then the people will have something to think about. > > here we have the typical chicken-and-egg problem: as long as > applications compiled with musl just crash, while they work perfectly > well with glibc, i think most contributors will become discouraged soon > and continue using what they're familiar with. Definitely you're right. That's why I don't suggest to "ignore them all" or something like that -- but may be at least we can let them know they do something wrong. Thanks! Andrey Stolyarov