Re: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>

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