| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 15, 2010 0:31 UTC (Mon) by nix (subscriber, #2304)In reply to: Glibc change exposing bugs by promotion-account Parent article: Glibc change exposing bugs
Linux man-pages are only authoritative for the kernel system-calls (more precisely, their glibc thin layer).No, even those are descriptive. Perhaps the glibc texinfo documentation would be authoritative for that, if it was ever maintained by anyone. As it is, I think only Ulrich and Roland's brains are authoritative for glibc.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 15, 2010 1:27 UTC (Mon) by promotion-account (guest, #70778) [Link]
I remember finding a good number of system-call manpages discussions in LKML. Otherwise, where should we find documentation for things like futexes, netlink sockets, and the rest?
For good or bad, these manpages are the 'most primary' sources available for such topics, only beside the code.
But unfortunately these man-pages do not always exist. I once had to carefully study the bluez userspace code to know how to best interface with the kernel Bluetooth API (undocumented AF_BLUETOOTH sockets, undocumented netlink interfaces, etc).
Glibc change exposing bugs Posted Nov 15, 2010 10:38 UTC (Mon) by nix (subscriber, #2304) [Link]
Yes, they are the most useful documentation we have, especially for things that do not have glibc wrappers. But even for the kernel they are descriptive, and for things for which the glibc wrappers are the primary implementation (like readdir()) or for which there is no kernel component, the manpages are completely after-the-fact. (As far as I can tell the glibc project no longer bothers to document anything at all. There are lots of utterly undocumented things in glibc's allegedly public interface.)
|
|||||||||||||