On 13-12-18 04:37 PM, Anton Aylward wrote:
Linda Walsh said the following on 12/18/2013 04:08 PM:
If they are, it is a bug.
And bugs should be reported.
Bugs in documentation are 'easy' compared to some others. You can propose a change instead of just complaining.
No, make that you SHOULD propose a change instead of just whining.
That's right, subject to the person who encounters the bug knowing how the program in question ought to behave, and that's what we did. But I have seen all too many cases where the person affected by the bug is not in a position to offer such a change. For example, if I am using a C++ compiler, and I find the documentation reflects the latest ANSI standard but the compiler does something different, then it is a bug in the compiler that I could only report (because it is certain I have never been masochistic enough to study all the code in the compiler to see how it supports all the features of the language I am using, and thus could not know how to fix the bug in question). But if the compiler does what is consistent with the ANSI standard but the documentation says something different, then I could suggest the change to the documentation because I understand the ANSI standard and see that reflected in the behaviour of the compiler. On the other hand, it is a safe bet that none of the students in a first course in C++ programming understands the extant standards well enough to know what the compiler ought to be doing: they could only see the discrepancy between what the compiler is doing and what the documentation says it should be doing. The appropriate course of action, then, depends sensitively on who it is that hits the bug. But don't forget, the case I mentioned occurred more than two dozen years ago, and often it was a defect in the original documentation, but even more often it was an error on our sysadmin's part, in not ensuring that the local copy of the docs was consistent with his optimizations. Only he had a hope of determining whether he messed up on his optimization or if he had neglected to update the documentation to reflect the optimizations he'd deployed. But, to add to our "fun" he often told us that the system is fully documented in the code (and he meant the code, not comments embedded in it), and that we ought to just read the code: a rather arrogant response to us as many of his changes were done in assembly (he didn't trust the c compilers of the day to get the optimization right), and he was the only person in the department that knew assembly. There were only about 4, out of a couple hundred, people in our department that knew how to write a program, and all of us, except him, developed our programs in fortran, c, or pascal. He expected us to take the time to learn assembly in order to figure out what he did (and I was never masochistic enough to bother with assembly), and then study the professional literature of the day to find out how operating systems of the day, and the applications he'd installed and optimized, ought to behave, and therefore how the system ought to behave in response to whatever command we were trying to use. How shall I say this: he was brilliant, but his 'people skills' were under developed. I am sure you have seen the type. I respected him, but he was often difficult to deal with. Cheers Ted -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org