NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD macros



At Tue, 22 Dec 2009 10:10:39 +0100, Jonathan Schleifer 
<js-netbsd-users%webkeks.org@localhost> wrote:
Subject: Re: NetBSD macros
> 
> Am 18.12.2009 um 22:25 schrieb Greg A. Woods:
> 
> > If the feature is found on multiple types of systems, but not all, and
> > for some reason you must still use it, then you should identify it  
> > by a
> > unique identifier and find some other way to enable that identifier,
> > other than messing about with system-specific identifiers.
> 
> 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.

> > (However, BTW, often the version checking is irrelevant because the
> > feature is, for this example say, a common BSD feature that was  
> > found in
> > the original code from which all the various modern variants have been
> > derived -- a wee bit of history goes a long way!)
> 
> 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!  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.


> 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.


> 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!?!?!?

> 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.

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?


> > 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?

> 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!

-- 
                                                Greg A. Woods
                                                Planix, Inc.

<woods%planix.com@localhost>       +1 416 218 0099        http://www.planix.com/

Attachment: pgpHMY3hcMHU7.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index