Glibc change exposing bugs

Posted Nov 15, 2010 0:00 UTC (Mon) by promotion-account (guest, #70778)
In reply to: Glibc change exposing bugs by nix
Parent article: Glibc change exposing bugs

What on earth? The relevant documentation for memcpy() is ISO C, incorporated by reference into all versions of POSIX.1.

Indeed.

Linux man-pages are only authoritative for the kernel system-calls (more precisely, their glibc thin layer). The rest of the APIs are only included for convenience: they are a secondary source to the primary source references residing in the 'CONFORMING TO' section.

Glibc change exposing bugs

Posted Nov 15, 2010 0:31 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

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.

Glibc change exposing bugs

Posted Nov 15, 2010 1:27 UTC (Mon) by promotion-account (guest, #70778) [Link] (1 responses)

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.)