On Sun, 12 Jan 1997, Andrew Warren wrote:

>     I'm not sure how the issue became "ANSI C" compatibility.
>
>     Mark didn't claim that his compiler was ANSI-compliant, and I
>     wouldn't hold any embedded-C compiler to that standard, anyway...
>     Although I mentioned ANSI once in my last nessage, what I was
>     really trying to discuss was whether the compiler was compliant
>     with the (admittedly less formal) definition of a "full" C
>     compiler.

What is "full C" if not the language defined by the ANSI/ISO standard?

>     We each may have our own ideas of what constitutes "full C" for a
>     small embedded processor.  Rather than nitpicking about features
>     like floats, pointers to functions, etc., I tried to choose
>     features and operations that are likely to be used in a small PIC
>     application.

That's fine and probably even sensible, but that approach will lead to the
situation where different folks have differetn ideas of what "full C"
means - I think we see that happening here, eh?

>     Again, I didn't mean for the issue to be ANSI compliance. Arrays
>     of bits (and/or pointers to bits) are VERY commonly used in PIC
>     applications; a compiler that supports single-bit variables should
>     also support arrays of, or pointers to, those variables.

Well, it would be useful, but this is not a notion that is supported by
the Standard C language.  Which, BTW, does have a bitfield type that comes
very close to being a single-bit variable, but there aren't any arrays of
them in the language...

I think the problem is that everyone has been tossing around ill-defined
phrases like "full C" with not agreement on what that might mean, and
that's pretty much a waste of everyone's time (ie, now more time gets
spent sorting out, and perhaps arguing about, the "correct" definition -
pfui!).

AndOfCourse all this other stuff also detracts from the valid, and I would
agree to say, serious, deficencies you described.