Alejandro Colomar <[email protected]> writes:
>> Still, for the next 10 years, C programmers would debate whether they should
>> #include <string.h> or #include <memory.h>. Different C programmers in the
>> same team will have different personal opinions. Thus, programmer team leads
>> will have to establish coding styles/guidelines which say which header to
>> include in this case.
>
> I find that an acceptable result.
But you aren't the only one who uses or references the man pages. From
this thread, many people are not happy with the change.
> #include's aren't that important. When reading code, the section of
> #include's is unimportant as long as it works.
In this case they won't "always work", hence your request that gnulib
and illumos make changes to accommodate your preferences.
>> I don't agree with you that it's "fair game". The SYNOPSIS is the first
>> eye-catcher, often the only part that a programmer reads. It would be a
>> disgrace if the man page, in the SYNOPSIS, mentions a different header than
>> the authoritative source.
>
> Some would question the fact that the glibc manual is the authoritative
> source for glibc documentation. :)
I am not sure why it wouldn't be? It is what the glibc maintainers most
actively update. It isn't perfect of course, but it does contain quite a
lot of information:
$ pdfinfo manual/libc.pdf | grep '^Pages:'
Pages: 1284
Collin
