> [T]hat was my point about extensions being disabled by default.  As
> you said in a previous posting, it's sometimes difficult to know if
> you're writing code that conforms to a particular standard.

It wouldn't really bother me if gcc's extensions were disabled by
default.  I already almost always use two wrappers which turn on a lot
of things that aren't on by default.

>> Sure, given ANSI C plus an X API, or a SunWindows API, or a GL API,
>> or whatever your favorite interface is, yes.  But the library behind
>> that API is going to use calls that ANSI C doesn't promise anything
>> about [...]
> I must be missing your point here, as I'm unable to see why my X
> system or whatever can't be written in ANSI C.

open(), mmap(), ioctl(), read()...ANSI C doesn't promise a thing about
them.  The library can be written in ANSI C, maybe, to the extent that
using include files and calls provided by the OS is permitted in ANSI
C.  That's why I've been careful to phrase it the ways I have: "as long
as you stick to things ANSI C specifies", "calls that ANSI C doesn't
promise anything about", that sort of thing.

I don't think this is unfair, because what we were discussing was the
"write once, run anywhere" aspect of ANSI C, and using facilities like
OS calls that ANSI doesn't promise anything about breaks that.

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