"Greg A. Woods" <woods%planix.com@localhost> wrote: > > And this is what autoconf does. > > However it is usually possible to find other ways to check for such > features, and sometimes even without using any external checks, just > built-in identifiers that indicate the feature is available. Please show me a built-in identifier that tells me whether getaddrinfo is available and if it's thread-safe. > > This is only true for BSD features, but is already false when it > > comes to POSIX features. Just think about getaddrinfo for example, > > which still is not thread-safe on OpenBSD and is also not > > thread-safe on NetBSD 3.x and FreeBSD 5.x. So you _HAVE_ to check > > versions here. > > No, you certainly don't have to check which OS you're using a standard > API on. You simply use that feature only in the ways it is compatible > with the _standard_ -- eg. in this case with getaddrinfo() you don't > try to use it from multiple threads! Ah, so you tell me to break POSIX, yes? POSIX says it's thread-safe. BSDs failed to have it thread-safe for a long time. > Be smart in the first place, > not after it's too late to do things right! Code that's not written > to be smart abut using _standard_ APIs in standards _conforming_ ways > in the first place is forever going to have to be debugged, ported, > fixed, and rewritten. Again: BSD is what is not conforming to the standard here, not me. If you say, go for the standard and don't care, then that would mean excluding BSDs (FreeBSD <= 5, NetBSD <= 3.1, OpenBSD every version). > > Who are you to decide whether a system is irrelevant or not? You > > can't know if it's still out there in productive use. It's not too > > long ago that they shut down the last multics systemÂÃÃÂ > > Actually it _is_ too long ago that they shut down the last running > Multics. 2000 is already very nearly ten, 10, 012, 0xA years ago! > That's a whole decade, i.e. a hundred years in Internet time! If it > were relevant to this debate then one could easily argue that everyone > could have stopped keeping newly written programs portable to it by at > least 1996, if not earlier, and certainly by 1998. > > As the author of the code one must decide based upon the effort > required to support a given system. > > It doesn't really matter if there's still some arcane system out there > being used productively by anyone -- what matters is whether there are > enough such systems which will _require_ your new program to justify > the effort necessary for you to attempt (usually without direct > access to any of these systems) to adapt your new program to run upon > them. > > Like you said, too many new programmers today are not bothering to > even make their code compile with any other compiler but GCC. > > And yet they still wastefully and pointlessly use Autoconf. That's nonsense. Just because your code only runs on gcc does not mean you don't need autoconf. That's complete and utter nonsense. gcc runs on so many platforms that differ in so many aspects that you need to check those. > > Yeah, right, if the standard APIs would be fully supported by at > > least one system. Neither GNU, nor BSD fully supports POSIX. And > > gcc does not fully support ISO C 99 either. > > And when did you last write code that absolutely had to use the > unsupported bits, or which tripped over the corner cases where the > real systems step beyond the bounds of the standards!?!?!? Today? How often do I need to repeat that there are even issues with fundamental stuff like networking? How often? Are you even listening? > > This is especially false for dependencies. Dependency libraries > > often change, for example. > > They'd damn well better not! Your system is borked if they do. No, it's not. Please read up on shared library versioning and which version changes allow you to do which kinds of API changes. Thanks. > Perhaps you're thinking of some world where good software hygiene and > proper software configuration management are not yet invented, or at > least not practiced? Then please tell me how "software configuration" (I assume you are talking about package management) is going to solve it. Refresh the cache each time a library is updated? Great idea! Let's do even more useless checks! *facepalm* > > > IFF the system does change, eg. you upgrade to a new version, and > > > IFF the system's APIs have changed incompatibly, then you need to > > > throw away > > > the cache and start fresh. You know when you've changed the > > > system, so > > > you know how to manage your cache file! > > > > So you want to update the entire cache each time you changed only > > a little bit to the system? Great, now _THAT_'s waste of checks! > > Huh? How'd you get that idea from what I wrote? Well, you just gave a similar idea again on how to handle a changed systemâ > > And what if I decide to compile a single application with another > > compiler? What if I decide to cross compile? What if I changed > > some flags with which some stuff is not available? > > Come on now -- don't be silly! Of course if you're not using the > standard system environment in its entirety, then you should not use > the cache file provided by the standard system environment! Then please tell me how to make sure that the cache file is not used by accident, as we all know that this is something that will happen in the real world. PS: Please stop CC'ing me, you should have noticed by now that I'm on the list ;). -- Jonathan
Attachment:
signature.asc
Description: PGP signature