der Mouse wrote:
>>>However, ANSI C is so constrained and crippled a language that [...]
>>
>>[...]  But when the basic C language support differs from compiler to
>>compiler, then the portability of C is undermined.
> 
> I don't think it does - as long as you write in "basic C", whatever
> that is, as far as I can tell it pretty much Just Works.  The problems
> arise when people write in gcc rather than C (ie, using some gccisms
> that aren't Cisms), either without realizing it or under the impression
> that it's actually C they're writing in.
> 

Mmm, and that 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.

> 
> 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
> (if indeed it's written in anything Cish at all).
> 

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. Is there too much
ambiguity in the C standard (all that undefined behaviour)? Obviously
at some low level, perhaps where the OS interacts with the hardware,
I may be depending on code written in assembler rather than C, but
all that C code above it *could* be ANSI compliant surely? Do
shortcomings in the C standard make it too torturous to avoid compiler
specific extensions in an OS kernel, (which would be news to me, as
a common criticism of Linux is that it relies on gcc-isms)? Or is it
that too many assumptions have to be made if relying wholly on ANSI
C?

Chris

-- 
chris.wareham@iosystems.co.uk (work)
cwareham@btinternet.com (home)