> Date: Wed, 07 May 2025 11:24:41 -0700 > From: "Greg A. Woods" <wo...@planix.ca> > > There is no _OPENBSD_SOURCE on OpenBSD. It is purely a NetBSD invention.
This serves to make it easier to port OpenBSD-specific code to NetBSD, and mark the fact that it's OpenBSD-specific, without encouraging more adoption of bad APIs. > Shouldn't strtonum() likewise be protected by _NETBSD_SOURCE on NetBSD? We are not exposing it by default in order to discourage its use. You should use strtoi(3) instead. See the man page for details: https://man.NetBSD.org/strtonum.3 > I see reallocarray() has also been added within the _OPENBSD_SOURCE as > well, and I think it too should only be protected by _NETBSD_SOURCE. We did not expose it by default in order to discourage its use, and to encourage reallocarr(3) instead which fixes its issues. See the man pages for details: https://man.NetBSD.org/reallocarr.3 https://man.NetBSD.org/reallocarray.3 Unfortunately, POSIX.1-2024 adopted reallocarray despite the flaws that make it barely more useful than -- and just as difficult to use safely as -- realloc(3), so it is also exposed by the appropriate _POSIX_C_SOURCE now. > Notably strlcpy() and strlcat() are not protected by this unique > _OPENBSD_SOURCE though they both were invented by and taken from > OpenBSD. Instead they are protected by _NETBSD_SOURCE. Probably for hysterical raisins. If we were doing it again, we might use _OPENBSD_SOURCE, or, maybe we just wouldn't adopt strlcpy/strlcat -- see the litany of warnings in the man page for details: https://man.NetBSD.org/strlcpy.3 > (Maybe _NETBSD_SOURCE should be changed to __BSD_VISIBLE too? There > could be some confusion from that I guess given it would offer different > symbols on different systems unless there's a _lot_ more coordination > and cooperation between the system's developers!) Absolutely not, that would break all kinds of code that already uses _NETBSD_SOURCE, for no benefit. It _might_ be plausible for sys/featuretest.h to have #ifdef __BSD_VISIBLE #define _NETBSD_SOURCE #endif or something like that, but that is a high-risk change that needs to be supported by a pkgsrc bulk build to consider, and it would need to be accompanied by a justification.
