As a compromise, can we have a way to enable the old behavior, and have
that behavior enabled by default for all of the code that Sun ships?
(I'm talking about an alternate implementation, enabled in the headers
via a #define or somesuch.)
-- Garrett
Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Perhaps we can have a compile-time decision, such as done with XPG4
>> versus Sun definitions of things like strtok_r, where broken code is
>> allowed to use -D_ALLOW_BROKEN_NULL_PRINTF or somesuch.
>
> That doesn't solve the problem.
>
>> It would then be a matter of a man page update to allow developers to
>> decide whether they need/want this behavior for their (broken) code.
>
> Developers on Linux and *BSD aren't reading Solaris man pages. The
> whole reason for this case is for making building and running existing
> softwar that works (regardless of what "we" think of the quality issue
> of passing NULL to printf) on other platforms.
>
> That means no environment variables no compile time flags, nothing.
> Just make our libc printf(3C) family not cause a SEGV like everyone
> elses, and do it all the time.
>
>
>> But then again, we do have 0 at 0.so.1, right?
>
> Right.
>
>
>> It *sounds* like there are two possible decisions before ARC. Either:
>>
>> 1) We continue to declare such behavior "buggy" (results undefined),
>> and offer workarounds ala 0 at 0.so.1
>
> That basically means derailing this case and all ARC members voting
> against it.
>
> If that happens I'll start an appeal.
>
>> 2) We redefine the behavior such that use of NULL here is declared
>> permissible, and we take the hypothetized hits (if any) to
>> performance and debuggability.
>
> This case doesn't need to do that either. All it needs to do is what
> it says is does, provide the same safety net that all the other
> platforms libc's that were mentioned do.
>
> I purposely said in the case that there are no documentation changes
> because we aren't changing the documented interface just the perceived
> behaviour.
>
>> My leaning is to #1. It seems like we're trying to make bad
>> applications happy, to satisfy what is probably a small minority of
>
> No I'm trying to make OpenSolaris actually useful. I have two friends
> that I've convinced to run OpenSolaris rather than Ubuntu and both of
> them have bumped into this problem for things they have built from
> source. Both are seriously competent technical people and have
> programming skills and understand why I explainn the problem; but they
> don't care wither it was valid or not. What they care about is that
> it wouldn't have happened on Ubuntu and to them that is an OpenSolaris
> adoption problem - to the point that I almost lost one of them back to
> Ubuntu despite him being desperate to use ZFS.
>
>> developers who feel that such use of NULL should be legal (despite
>> documentation to the contrary) -- and who are unwilling to use a
>> perfectly reasonable workaround, at a potential cost to the greater
>> set of well-behaved applications.
>
> The workaround in my opinion isn't reasonable at all. You have to
> know you need it and you only find that out after you have a core
> file. Even if you have the core file you have to have the skills to
> do the analysis and realise that using the LD_PRELOAD=0 at 0.so.1 will
> help. While you and I can do that not everyone who is capable of
> doing: tar xf - ; ./configure ; make install is. It is those people
> that I'm helping.
>
> So I take that as you volunteering to fix every single upstream bit of
> FOSS that depends on the behaviour because it works just fine on
> Linux,OpenBSD,FreeBSD,NetBSD,SunOS 4.x,AIX,HP-UX.
>
>> It may be that some feel that the options presented here are an
>> implementation detail. But, I'm not convinced. If we feel so
>> strongly that we need to offer this behavior *by default* (and as the
>> submitter proposes, without any alternative to disable it), then we
>> should be willing to stand by it in the form of a documented promise.
>
> I don't think we should for the reason that Don sited. The standards
> say the behaviour is undefined. All the other important
> implementations, and even the other /usr/4lib/libc.so we still ship
> today, as a non destructive and completely standards compliant behaviour.
>
> IMO this is a case of purity over reality. I'm on the side of reality
> here.
>
> You aren't going to get me to change my mind. I was in the same camp
> as you for a long time but that doesn't win us new users and help
> OpenSolaris get to use all the same "cool" apps as everyone else.
>
> Nobody else was a way to turn this off so I don't see why we need one
> either. We do have DTrace which if you desire can help you find
> this. It is also possible that lint or valgrind or purify can help
> find this too.
>
> Don't punish the OpenSolaris user because of choices made by original
> developers of software (FOSS or closed ISV) that originate on other
> platforms and remember SunOS 4.x had the same behaviour this case now
> proposes which is probably why GNU libc has it!
>
