>> 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.
>
It's a bug in the script (non-standard conforming invocation.
I find no support for the position that it's a bug in printf.
>For example, the Marvell script still works correctly; the user just
>receives some unexpected error messages.
Right, but that might be an issue.
I strongly believe that both implementations are standard conforming;
the invocation is a non-conforming one so we get into the realm of
compatibility in error conditions. Unfortunately, that's one of
the things you can't test for and, if you never change this, you
will impede progress.
Clearly, if the standard at one point introduces an option to printf
then the script will break regardless.
>> > 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.
Right, but one can argue that the requirement to precede arguments with "-"
always with "--" is arcane knowledge.
>support at syskonnect.de, apparently.
>
Right, though they have not always been equally responsive.
Unfortunately, there are some persistent bugs in the Yukon driver:
- doesn't work when kernel memory debugging is enabled (fails to
load)
- two different driver names for 32 and 64 bit it seems
(and not in a single package)
- there are at least three different "but the same" drivers for
chipset: Yukon, tcge (3COM) and skge (SysKonnect)
- they inist on configuring the device driver from the
pkgadd script (double yuck)
And we really want to ship it with Solaris. I think we all really want to
help them make the driver work better for Solaris
Casper
