> i don't object to extentions to the language, but i do object to them
> not being properly added to the ANSI standard,

Standards, by their very nature, are always playing catch-up.  Ideas
are implemented, tried out, the good ones catch on (FSVO "good"), and
are added to the next version of the standard.

> the whole point of which was that it didn't matter what compiler you
> used, since they were all ANSI C compliant, your code Just Built(TM)
> on any of them.  that is so far from true today it's revolting.

It's not all that far from true - *if* you write in ANSI C.

However, ANSI C is so constrained and crippled a language that it's
difficult to do anything useful while still sticking to code that has
standard-specified behaviour.  A few filters can probably be written in
pure ANSI C.  Maybe even something ed-like.  I doubt anything requiring
much more OS interaction could be.

POSIX helps, some, in that it tries to standardize some of the
commonest ways of going beyond pure ANSI C, attempting to codify the
core of what makes UNIX UNIX, to put it loosely.  Given the magnitude
of the task, I think they did a decent job - but it still has many of
the same problems, and worse, few-to-no systems truly support
POSIX-compliant code.  And to make it even worse than that, few coders
even know when they're going beyond what POSIX promises - I sure know I
often don't.

> porting used to be handling quirky differences between platforms, and
> in most cases was a rather small task.  porting these days means from
> GCC C to ANSI C because not only do some of us think commercial
> compilers kick butt,

In some respects they do.  In other respects they suck majorly.  (And
of course, speaking of "commercial compilers" as if it were a
homogenous class is about as accurate as speaking of "coders" as if
they were all the same.)

> in some cases GCC doesn't generate good code, or sometimes doesn't
> generate working code at all (i am constantly reminded of that with
> SPARC64 and MIPS64)

Yeah, having no gcc support on a platform is a pain when you want to
run code written in gcc on that platform.

But the same is just as true if you s/gcc/Python/g, or s/gcc/Icon/g, or
pretty much any other language - even C.  I can't see how gcc differs
from Python, or Icon, or anything else, except perhaps in the volume of
code written in it...and, I suppose, the extent of the confusion
between it and another, similar, language (namely C).

/~\ 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