Re: NULL

[croco@openwall.com]

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