Recent Features
| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 14, 2010 22:29 UTC (Sun) by nix (subscriber, #2304)In reply to: Glibc change exposing bugs by gus3 Parent article: Glibc change exposing bugs
The GNU people should own up to having violated the documentation on their code.What on earth? The relevant documentation for memcpy() is ISO C, incorporated by reference into all versions of POSIX.1. This clearly states "If copying takes place between objects that overlap, the behavior is undefined." This isn't an obscure or hard-to-interpret part of the Standard. Undefined, bang, that's it. Perhaps you are operating under the misapprehension that the linux manpages project, a descriptive effort, not a prescriptive one, is in some way binding on glibc? It isn't. It really isn't. It isn't binding on anything.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 15, 2010 0:00 UTC (Mon) by promotion-account (guest, #70778) [Link] 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] 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]
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.)
|
|||||||||||||