[cc'ing kre@ for the first hand information] On Mon, Aug 10, 2026 at 15:06:50 +0200, Ingo Schwarze wrote:
> Arsen Arsenovic wrote on Mon, Aug 03, 2026 at 11:09:40PM +0200: > > enh <[email protected]> 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(); ... > 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. ISTR (from the very early 90s) that memory.h was indeed the SysV thing. This was before autotools, so e.g. GNU programs shipped with a bunch of config.h files in a subdirectory and you had to choose the right one. Our SysV was a weird cross-over that didn't quite match anything, so that was ... a very valuable learning experience. BSD and derivatives were still using <strings.h> at the time and <string.h> and <memory.h> were a SysV thing. When things settled in favor of <string.h> that subsumed mem* functions, <memory.h> became redundant, but for the sake of old programs it was logical to make it just forward to <string.h>. -uwe
