On Feb 17, 2008 7:51 PM, Roland Mainz <roland.mainz at nrubsig.org> wrote: > Shawn Walker wrote: > > On Feb 8, 2008 10:15 AM, <Casper.Dik at sun.com> wrote: > > > >printf also has to ingore -- so that an old script that does > > > > printf -- > > > >will no longer generate output. > > > > > > That part Solaris printf does properly. > > > > Roland commented that: > > > > "Erm... what should we do in this case ? The upcoming changes for > > /usr/bin/printf in OS/Net will trigger the same error in those scripts > > (remember it's stabilty status "Standard" since /usr/bin/printf _must_ pass > > the > > VSW&co. test suites)." > > > > I'm a little lost here on how Sun typically handles cases like these. > > AFAIK it's a "bug" and not an "incompatibity". The Marvell package > script described in http://defect.opensolaris.org/bz/show_bug.cgi?id=502 > just hits the unfortunate case where 1) an utilty in Solaris does not > implement the POSIX standard correctly and 2) something external (the > Marvell package script) relies on this behaviour. > AFAIK there are two options in this case: > 1) Treat the issue as bug in /usr/bin/printf and report problem in the > Marvell script to the vendor
That should be done regardless, in my view. > 2) Treat the issue as a compability issue. In this case we have to > change the stabilty status of /usr/bin/printf from "Standard" to > "Commited", create /usr/xpg6/bin/printf (as location for the version of > "printf" which fully conforms to the standards) and bind the ksh93 > builtin to /usr/xpg6/bin/printf (as a side-effect we wouldn't be able to > implement all the C99 features in /usr/bin/printf since this would > change a commited interface) I'm not so sure about that just yet. For example, the Marvell script still works correctly; the user just receives some unexpected error messages. > > What happens when a bug-fix causes unexpected behaviour in programs > > and they are not exactly doing something *intentionally* wrong? > > It depends on the case. In this particular case it seems the Marvell > authors didn't read the manual pages and just did some trial&&error > testing with Solaris's current implementation of /usr/bin/printf This I agree with. > > In this case, it looks like ksh93 won't cause any more problems than > > the upcoming changes. > > > > With that in mind, it seem as though this could be considered a non-issue? > > AFAIK this is a non-issue unless the "Interface Stabilty" of > /usr/bin/printf gets changed from "Standard" to something else. ksh93's > "printf" builtin passes the POSIX test suites (and I better not start > ranting about the current /usr/bin/printf implementation in Solaris > (which doesn't implement any C99 features, mis-handles multibyte > characters, creates values out of nowhere, sometimes just crashes etc.)) > and this is AFAIK the only thing which really counts in this case. I tend to agree; I just think it would be helpful if a page was put up on the ksh93 integration project page that detailed what the approach and plan is to deal with bugs, incompatibilities, etc. Even if ksh93 isn't the one directly responsible for breakage; a plan needs to be in place to deal with issues and a set of guidelines established so that they are *consistently* dealt with. > P.S.: Does anyone know how we can file a bug report to Marvell ? support at syskonnect.de, apparently. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben
