Thanks for your reply Taylor! At Thu, 8 May 2025 00:50:44 +0000, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote: Subject: Re: use of the uniquely NetBSD _OPENBSD_SOURCE vs something better? > > > 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 must admit I entirely missed the previous discussion about this in 2014, and somehow it didn't come up in my brief searches about the issue yesterday. I'm not sure I would have appreciated the implications of this all back in 2014 -- I didn't even discover the need to hack code to work around it until 2017. OK, so, anyway, I understand the background now. However this special define does impose extra effort to port code to specifically to NetBSD, as now strtonum() is more or less "universally" available by default. (I've since seen that it is available by default in Solaris (illumos, OmniOS), and of course it's also been in the linux "BSD" library, with default visibility, for a very long time now.) In any case it seems mostly like politics and bad grudges to require a unique special define to expose these functions to code that end users are just trying to build. Sure, discourage them in the documentation, point to better designs, maybe even add compiler warnings, maybe also use those compiler warnings to continuously audit NetBSD code to make sure it doesn't miss-use them, but why entirely hide them (by default) from third party code that end users just want to build and use on NetBSD? The rest of the world thinks (if they do at all) that NetBSD is "Just Another BSD", and so it should have all the same features as all those other BSD, right? Why should third party code have to add yet another special, but very oddly confusing, define just to compile code using a "BSD" function on NetBSD? I'm going to get laughed at trying to suggest fixes to projects which effectively say they have to define "_OPENBSD_SOURCE" just to compile stuff on NetBSD when it already works on all the other BSDs! #if defined(__NetBSD__) && !defined(_OPENBSD_SOURCE) # define _OPENBSD_SOURCE 1 #endif A compiler warning is only going to annoy NetBSD users, but having to add the above to code is going to annoy _everyone_ else, and by "annoy" I mean it definitely won't point them at better APIs! Unrelated rambling: > > (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 Sorry, I didn't explain that very well at all. That's kind of not what I meant. __BSD_VISIBLE is an internal macro, not a control macro (something equivalent might be _BSD_SOURCE, but that one in particular has fallen out of favour in the glibc world). So, I was thinking more the other way around. Obviously the end result shouldn't cause any visible change to appear to applications. I was more thinking of the way FreeBSD and OpenBSD manage the feature-test macros and how they have created these internal __foo_VISIBLE flags to separate the way features are exposed from the user control flags like _foo_SOURCE, etc. In any case that's probably way too much of a make-work project. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpM36n4O3d63.pgp
Description: OpenPGP Digital Signature