| |||||||||||||
Quotes of the week - all about documentationQuotes of the week - all about documentationPosted Dec 11, 2008 18:02 UTC (Thu) by faramir (subscriber, #2327)In reply to: Quotes of the week - all about documentation by etienne_lorrain@yahoo.fr Parent article: Quotes of the week - all about documentation
Bug? What does 'bug' have to do with documentation? Bugs go in bug tracking system (which seem to be pretty rarely used by kernel developers as well). Documentation is what describes how something WORKS, not how it DOESN'T WORK. When code/doc is out of sync then there is a bug which goes into the rarely used bug tracking system and hopefully something gets changed eventually to to put them back in sync.
Should people really have to read the GLIBC code in order to figure out how to use printf() for their first "hello world" program? Why should I have to (potentially) read all of the kernel source in order to write a device driver? Not documenting standard support routines is likely to result in MORE bugs in code that uses it as developers misunderstand the intricacies of how to use those functions.
(Log in to post comments)
Quotes of the week - all about documentation Posted Dec 12, 2008 1:58 UTC (Fri) by Lumag (subscriber, #22579) [Link]
Is there lots of documentation regarding extending GLIBC? Because there are pages describing kernel <-> user interface (Analogy to printf).
Quotes of the week - all about documentation Posted Dec 12, 2008 13:55 UTC (Fri) by nix (subscriber, #2304) [Link]
Emphatically no. A lot of glibc's nifty features (LD_AUDIT,
_MALLOC_PERTURB, a lot of others) don't seem to be documented *anywhere*. A good few (e.g. the asychronous resolver) aren't described in the glibc manual but only in pdfs on Ulrich's homepage (the first place anyone would think to look, although Google saves you there).
|
|||||||||||||