From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2536 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 17:09:27 +0400 Message-ID: <20130109130927.GA2947@openwall.com> References: <50ED4E45.6050801@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 1357737773 28797 80.91.229.3 (9 Jan 2013 13:22:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2013 13:22:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2537-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 09 14:23:10 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 1Tsvca-0001yd-Sh for gllmg-musl@plane.gmane.org; Wed, 09 Jan 2013 14:23:09 +0100 Original-Received: (qmail 10201 invoked by uid 550); 9 Jan 2013 13:22:52 -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 10193 invoked from network); 9 Jan 2013 13:22:52 -0000 Content-Disposition: inline In-Reply-To: <50ED4E45.6050801@barfooze.de> User-Agent: Mutt/1.5.18 (2008-05-17) Xref: news.gmane.org gmane.linux.lib.musl.general:2536 Archived-At: Hi folks, On Wed, Jan 09, 2013 at 12:02:29PM +0100, John Spencer wrote: > so for me, there are 3 options how to deal with issue in the future: > 2) change musl so it is compatible with those apps. this would mean: > #if defined(__GNUC__) && defined(__cplusplus__) > #define NULL __null > #elif defined (__cplusplus__) > #define NULL 0 > #else > #define NULL (void *) 0 /* for C code */ > #end > this change is the easiest solution: any problem will be magically fixed. Actually, the problem is not fixed this way; this just gives the problem the right (hmmm.. license, heh) to exist forever. My experience of teaching students shows that when smart people introduce something to help stupid people to remain useful without learning, we end up with more people who don't want to learn, and that's all (arhgggg, I hate the one-unknown-to-me who decided one day that two object modules having global variables of the same name and type should link successfully... so that newbie can simply place 'int my_damn_var;' line into his/her header not bothering with understanding of 'extern' and the linker as such, and then they tend to ask the well-known thing 'why do you say this is incorrect if it works') However, sometimes the practice forces us to do wrong things just because we have no time or resources to do what is the right, and it looks like this is exactly the case. So perhaps the "option 2" will finally be 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. 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. Thanks! Andrey Stolyarov