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

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4725 bytes --]

Hi Mark,

> Date: 2026-08-03 10:58:35-0700
> From: Mark Harris <mark.hsj@gmail.com>
>
> Alejandro Colomar wrote:
> >              Most C libraries, including the  BSDs,  glibc,  and  musl,
> >              provide <memory.h>.
> >
> >              Illumos  and  gnulib don’t provide it, though, and instead
> >              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

Oh, I was expecting to find it under some .../include/ directory.
I didn't expect .../head/, and thus my confusion.  Thanks!

I'll amend the documentation to say that it also includes is.

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

Thanks!  I'll also document this detail.

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

Huh!  :)

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

Luckily, the modern BSDs have it as a synonym of <string.h>, and so is
musl and glibc.  (I guess bionic too.)

But I'll document this detail.  It is important.

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

I wouldn't say a lot, but certainly some.

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

I've been in contact with the implementors of the MS libc for quite some
time already for the fix of realloc(,0) in which I've been working.
I might have a handle there.  :)

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

The manual pages document the standard header file, of course:

	     #include <memory.h>  // See STANDARDS

	STANDARDS
	     C11, POSIX.1‐2008.

	     ISO C and POSIX declare this function in <string.h>; see memory.h(3head).

Thanks for the details!


Have a lovely day!
Alex

>  - Mark

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]