Re: CVS commit: src/lib/libc/gen

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 3 Mar 2025 18:08:17 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20250303180830.D601784DE1%mail.netbsd.org@localhost>

  | I did test build, and I ran the arc4random tests, including the test I
  | added to verify the new more-graceful failure mode.  I just forgot to
  | add one file in the commit.  With that file added the tree is fine
  | again.

yes, I saw that.   I initially assumed that it was one of those private
libc include files not being found things (I have seen that happen before).

  | I think it is a trifle excessive to characterize a never-fails variant
  | of pthread_atfork with caller-allocated storage as insane.

excessive perhaps, but that is still a very poor design choice, as bad
as making the FILE struct publically visible, which means it can never
be changed (same with struct tm).   None of this kind of thing should
ever use external private storage other than char buf[NNN] type things.

If we were designing a pthread_atfork() kind of interface, a method in
which the data struct was passed in might be how it should be done, with
just minimal knowledge (in libc) of what that data struct contained.

But we're not - inventing a new private interface for NetBSD isn't a good
solution, we still have to support the existing one, and if we're doing
that we may as well just use it, warts and all (and keeping its internals
completely private so nothing else cares if they're changed).

Other systems seem to cope with that, we can make a version which never
fails in any realistic scenario (certainly not early in a process lifetime)
and I have (off list) promised to make that happen, and I will - though I
will send my proposal to current-users before I commit it.

  | But since this change is evidently controversial, which I hadn't
  | anticipated when I committed it, I'll revert it for now.

Thanks.

kre