Re: proposed revision to memory.h(3head)

Alejandro Colomar wrote:
>              Most C libraries, including the  BSDs,  glibc,  and  musl,
>              provide <memory.h>.
>
>              Illumos  and  gnulib don=E2=80=99t provide it, though, and i=
nstead
>              use <string.h>.

I don't understand why you claim that illumos does not provide a
memory.h.  It clearly does:
https://github.com/illumos/illumos-gate/blob/master/usr/src/head/memory.h

However, it only declares the 5 functions that were historically
declared there: memccpy(), memchr(), memcmp(), memcpy(), and memset().
Including memory.h is not going to pull in declarations of functions
that have always been defined as being in string.h, such as the
strn*() functions.

This matches what was found in SVR4, the first System V release that
was fully unified with standard C and claimed compatibility, and which
was the basis for many commercial Unix systems.  For backward
compatibility SVR4 retained memory.h with the 5 original mem*()
declarations, and those declarations were duplicated in string.h for
standard C conformance.  They did not even add memmove() to memory.h;
it was only added to string.h where the standards committee added it.

Also in 4.3 BSD, when they added memory.h for System V compatibility
in 1986, it only declared the 5 original mem*() functions.  It did not
include string.h or declare any str*() or strn*() functions.

So I think you will find that a lot of systems that were following
System V or 4.3 BSD may have a memory.h, but it is not going to work
the way you are suggesting in the man page.

> > New programmers will follow those
> > instructions and find their code breaks on illumos, when it really
> > shouldn't.
>
> I hope Illumos adds <memory.h>.  Also, I don't expect new programmers to
> be exactly the kind of programmers that use Illumos.

What operating system do you think is most used by new programmers?
You are right that it isn't illumos; it is Microsoft Windows.  I'm no
Windows expert, so perhaps someone else can confirm, but it appears
that Microsoft's C runtime also has a memory.h that declares some
functions like memcpy(), but not any strn*() functions which have
always been defined to be in string.h.  If it's not even in ISO C I
doubt you will have much luck convincing Microsoft to add the
functions that you decided should be in memory.h.

Suppose I was reviewing some code intended to be portable, that
included memory.h for a function that ISO C and POSIX say is declared
in string.h and that isn't even one of the 5 original mem*()
functions.  Even if memory.h works on the author's system, it is by
accident.  Using the standard string.h header that almost every
implementation for decades has strived to comply with avoids easily
preventable build failures when attempting to build the code
elsewhere.  So I would of course reject the code and point the author
at the ISO C or POSIX standard.  Perhaps you wouldn't because you are
willing to fight the other operating systems that don't provide the
nonstandard memory.h that you prefer, but I am not willing to do that
and I doubt there are many people willing to take up that fight for
you without a large standards body like ISO C or POSIX backing them
up.  I don't want to tell people that the man pages cannot be trusted
for accurate information, so I hope that you will not lead me to do
that just to avoid the introduction of non-portable code that will
cause problems on conforming implementations.


 - Mark