Re: on project management

On 2026-08-11 05:49, Robert Elz wrote:
> I replied to Paul with more details, I saw the reply got to UCLA
> mail servers, but whether he received it, or it was treated as
> spam, I have no idea.
I got it. Thanks for the trip down memory lane. The amusing thing to me is how 7th Edition Unix got by without a single mem*-style function. When 7th Edition code wanted to (say) copy a block of memory it did so by hand, byte by byte.

Here are you sent me in your email dated Tue, 11 Aug 2026 03:56:27 +0700:
>     Date:        Mon, 10 Aug 2026 10:29:12 -0700
>     From:        Paul Eggert <[email protected]>
>     Message-ID:  <[email protected]>
> 
>   | In an email today[1], Ingo Schwarze mentioned your contribution to
>   | what became 4.3BSD,
> 
> There was some of that yes, starting around 3BSD, but:
> 
>   | a contribution that introduced <memory.h>.
> 
> I have no memory of anything related to that, and it sounds kind
> of unlikely  -- but that is all so long ago.   When I look in
> the sccs logs of memchr.c I see:
> 
> D 5.5   90/05/15 14:07:06 bostic        5 4     00022/00020/00011
> ANSI C version from Chris Torek
> 
> D 5.4   88/06/27 18:25:34 bostic        4 3     00010/00005/00021
> install approved copyright notice
> 
> D 5.3   88/05/25 14:23:52 bostic        3 2     00010/00008/00016
> written by Robert Elz; add Berkeley specific header
> 
> D 5.2   86/03/09 19:33:58 donn  2 1     00001/00001/00023
> added LIBC_SCCS condition for sccs ids
> 
> D 5.1   85/08/05 21:43:13 kre   1 0     00024/00000/00000
> date and time created 85/08/05 21:43:13 by kre
> 
> so I guess I probably did have something to do with some of it.
> 
> The comment at the top (after the copyright nonsense) says:
> 
> /*
>  * Sys5 compat routine
>  */
> 
> It included no header files.
> 
> But there was a <memory.h> created at about the same time:
> 
> D 5.4   90/05/15 19:43:57 bostic        4 3     00001/00001/00019
> string.h is ANSI C include file
> 
> D 5.3   90/02/12 12:20:39 bostic        3 2     00001/00005/00019
> might as well only have one copy.
> 
> D 5.2   88/08/12 14:13:46 bostic        2 1     00020/00013/00004
> correct list from manual page
> 
> D 5.1   85/08/05 21:21:49 kre   1 0     00017/00000/00000
> date and time created 85/08/05 21:21:49 by kre
> 
> The 5.3 change altered it to just be #include <strings.h> and then
> the 5.4 change made that <string.h>
> 
> (In both cases there were later revisions than shown here, but they're
> mostly just updates for 4.4 type stuff, different copyright/licence, etc,
> rather than anything substantive).
> 
>   | Ingo writes that the code's comment "appears to claim that <memory.h>
>   | along with these five functions [memccpy, memcmp, memcpy, memchr, memset]
>   | came from AT&T System V UNIX,
> 
> "came from" in the sense that SysV created those functions, and then
> CSRG (me it seems) made BSD implementations - they are all trivial.
> 
> 85 was probably the year I spent 3 months working at CSRG (I certainly
> remember there was such a 3 month period - I also remember never bothering
> to fill in a California Tax return, and recover the (about) $10 refund I
> would have had coming...   But I no longer actually remember which year that
> was.)
> 
>   | almost half a decade before ANSI C 89 standardized them to
>   | live in <string.h>."
> 
> Certainly could be - whether SysV used <memory.h> or whether that was an
> invention, I have no idea.
> 
> The comment at the head of that one just says:
> 
> /*
>  * Definitions of the Sys5 compat memory manipulation routines
>  */
> 
> No indication if SysV used the same file name or not.  If I had
> to guess, I'd suspect possibly so, as I doubt I would have called
> it "memory.h" had I been inventing its name - so that probably came
> from wherever the specs for the functions came from.
> ,,,
> I didn't check the other 4 functions, but if I wrote the initial version
> of memchr() for BSD, it seems likely I wrote the others as well, but the
> version distributed seems likely to have been Chris Torek's rewrite.
> My version had K&R C style function definitions.