Re: on project management

[Ingo Schwarze <schwarze@usta.de>]

Hello,

Arsen Arsenovic wrote on Mon, Aug 03, 2026 at 11:09:40PM +0200:
> enh <enh@google.com> writes:

>> the crazy part is that it was an _empty_ file until i made it just
>> #include <string.h>:
>> https://android-review.googlesource.com/c/platform/bionic/+/52171
>>
>> i can't explain that (it was originally checked in as an empty file,
>> so the history is no help).
>>
>> i _can_ explain why i made it match glibc rather than just deleting it
>> though: i didn't want to break existing code that was [harmlessly]
>> including an empty file, and i wanted to increase the amount of the
>> code from other libcs that would "just work". (and note that ios/macos
>> have a <memory.h> that's just a #include <string.h> too.)

> I think this partially confirms my suspicion earlier, that the only
> reason anyone ever included <memory.h> is because on some system stuff
> they wanted was not in <string.h> (but was only in the latter on some).
> So the former tends to be included only when the latter is also, to
> cover both cases.

I think i can improve this understanding by providing some historical
facts.  While <memory.h> almost certainly did not originate in BSD,
BSD history can still provide some hints how it came to be.

The earliest instance of <memory.h> i'm able to find in my private
archives of free historical source code archives is this
file include/memory.h from 4.3 BSD:

  /*
   * Copyright (c) 1985 Regents of the University of California.
   * All rights reserved.  The Berkeley software License Agreement
   * specifies the terms and conditions for redistribution.
   *
   *      @(#)memory.h    5.1 (Berkeley) 85/08/05
   */

  /*
   * Definitions of the Sys5 compat memory manipulation routines
   */

  extern char *memccpy();
  extern char *memchr();
  extern int memcmp();
  extern char *memcpy();
  extern char *memset();

[I must admit the Copyright & license header feels bogus to me.
 According to the SCCS logs, the person who originally checked
 in this file into version control was Robert Elz <kre@>.
 It seems highly unlikely that Robert - or any other UCB
 employee or associate - wrote these function prototypes.
 On top of that, function prototypes are not usually considered
 Copyrightable, and even if they were in principle, there is
 barely any copyrightable text here.
 Then again, none of this matters much, if you put a Copyright
 notice on an empty or almost empty file that contains nothing
 Copyrightable, the notice simply means nothing.]


This comment appears to claim that <memory.h> along with these five
functions came from AT&T System V UNIX, almost half a decade before
ANSI C 89 standardized them to live in <string.h>.

While, as others observed, many systems still contain <memory.h>
as a thin compatibility wrapper around <string.h>, having it doesn't
seem particularly important at this point.  Who wants to really
maintain compatibility with System V based systems that are about
35 to 40 years old and significantly predate ANSI C?

That said, i believe the reason most systems did not outright
delete <memory.h> is that i fail to see an easy argument what
benefit exactly that might provide, apart from general cleanliness.

> I'd confirm definitely by getting the list of files from Debian
> codesearch that include one and the other and comparing it, but I wasn't
> able to figure out how to do that.

I fear you may be looking at entirely the wrong era.
The Debian project can be considered way too newfangled to provide
any substantial insight here.  :-D

Yours,
  Ingo