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! -- Darren J Moffat
