>> I have no intention of making it *necessary*.  I'd like to make it
>> *possible*.
> As I said, I have no problem with adding a couple of extra macros
> ([...]), but I'm not sure that they would do you much good.

Oh, they would, they would.

Well, at least for my own values of "good".

> After all, your aim is to write portable application code,

It is?  Where did you get that?  My aim is to write *clean* application
code.  That overlaps with many forms of portability, but neither is a
subset of the other.  (As an example of cleanness at the expense of
portability, I do not hesitate to use gccisms such as nested functions,
because they make some code a great deal cleaner to my eye, even though
they render the code uncompilable by non-gcc compilers.)

> and these days, that means more portable to different OS's than
> portable to different architectures (though both are important).

I don't know where you got the idea that you know more than I do about
what kinds of portability I care about, but you are wrong - both in
that and in your ideas about what kinds of portability I care about.

I care far more about writing clean code that's portable across
architectures than I do about writing code (clean or not) that's
portable across OSes.

> If the extra macros were added to NetBSD, you still wouldn't be able
> to use them in your portable code, or it wouldn't work on Solaris,
> MacOS, Linux, ...

Which wouldn't bother me.  Much of my code doesn't work anywhere but
NetBSD already, and almost all of the remainder is by coincidence
rather than by design (ie, it's because I don't happen to have used any
of the things that would render it NetBSD-specific rather than because
I've made any effort to avoid them).  Some of it won't even build
anywhere but my own systems, for (potentially) multiple reasons which
require various degrees of effort to install on other systems; I can go
into more details if you're interested, but that should probably be
done off-list, and certainly off-thread.

> The only solution to this kind of thing is to get the standard
> interface improved so that it avoids the problems -

Indeed.  And how can I do that without having an implementation of my
proposal to point to?  Innovation requires an innovator, requires
someone to be first.

Of course, I can do that without involving NetBSD per se, and if
necessary I will.  But I had thought NetBSD was about writing clean
code, and - at least to my own eye! - macros such as I proposed permit
significantly cleaner code.

> whether your proposed method is the best way to do that or not I'm
> not sure (it's more a way that works for you with minimal changes,
> which is not necessarily the best final solution).

True.  If you'd like to try to hash out a better interface without even
considering compatability, I'd be interested.  But I'd also like to
make small-step improvements while we're discussing large-step
improvements.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B