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

--2ghrdnsev6rf3k3m
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: Mark Harris <[email protected]>
Cc: "G. Branden Robinson" <[email protected]>, 
	Keith Bostic <[email protected]>, [email protected]
Subject: Re: proposed revision to memory.h(3head)
Message-ID: <anDgpLT-FlRrJKC2@devuan>
References: <am4GT1OkqNZD9FF9@devuan>
 <[email protected]>
 <am4jxBOh_VRvhCQw@devuan>
 <CAETFuj2OwoyK9J85r2f0RoXbHbXKA4gQJ=JZ-7=QoqGcMwk0+Q@mail.gmail.com>
 <am51v4KmUmdzM-OT@devuan>
 <am5_uA4MSujYCS9X@devuan>
 <20260801235332.vc443gozbqkqdqm5@illithid>
 <am6HTtAMkEEkWjfl@devuan>
 <am_jYJL6uAapMGXN@devuan>
 <CAMdZqKGRJuR_Jyt7TapMQFQ-6wz=OF5DROFhXkZLQNAn2vyimQ@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAMdZqKGRJuR_Jyt7TapMQFQ-6wz=OF5DROFhXkZLQNAn2vyimQ@mail.gmail.com>

Hi Mark,

> Date: 2026-08-03 10:58:35-0700
> From: Mark Harris <[email protected]>
>
> 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=
 instead
> >              use <string.h>.
>=20
> 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.
>=20
> 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=E2=80=902008.

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

Thanks for the details!


Have a lovely day!
Alex

>  - Mark

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

--2ghrdnsev6rf3k3m
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmpw4koACgkQ64mZXMKQ
wqlItw/9GznrnqREABpz1zoETX13xFfzC5PD358/FYvEiVF35TDNfKbuWQIJV8he
nDh9qxHxK8HDZ3XJmt2f7te7tci0J/80yjX00e3iqlDmoNI5riIRqAVsKxPiCmLz
52S7lEecVxyAd0Zj389TXDgWIrJ2B+5tJDV5lyzHlN5/ogMnGASfmAfe97kVZf62
4jrQUMTTvh8q4hyfcKOoP9loN6d7xfhg+gNkSLw/oOYK6jdrLsF7sxLjRKMNtHGC
qYCa6mSvnJwdXBFkAb8xJ7jOAT8X9H9BT86ZchHZYQCNF8blLZEvFsZGRsQX3YZ/
LGaNmvgU7FN254UAf1Lz4cN2Hna2abvViUI18PbuEZYVgdJGFHVgD9RgWYjwr/le
+BXtLdaw2lqmblndRHK1Kdx4BFbfLVfLHJPSUAzyQnIoqLD+jhrEXa5Rn5IOEhAA
zLrUX8Zp5UugQXQZbl2V6wq4UQBsNh+0WUNuELoCiSgPnOI+lZ7vSQE/t+nNHa+M
9KpUWfyn9mfcWDOcnCBcQfTLP5IC4DXT4WrNsRkUxOvsRBpSlg4J4RjECDzYztjM
VNKt7YCgL/2tZe5xuwZ4eJss7AsLna9/57DY0/zE5lpaN+dCu1KHdCH1yIRoWq9T
LO9GjnGPHNiN5X7yv0pnM+TlZEefJtzUmRw8dhncK0Ue/uUWMJM=
=1fk/
-----END PGP SIGNATURE-----

--2ghrdnsev6rf3k3m--