Whay is a C compiler ANSI compatible?

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:I5-dnbfoa5_8mHrbnZ2dnUVZ_uTinZ2d@web-ster.com...
> On Tue, 11 Sep 2007 21:04:54 +0100, tim..... wrote:
>
>> "Tim Wescott" <tim@seemywebsite.com> wrote in message
>> news:pt6dnZXBjouaeXvbnZ2dnUVZ_vHinZ2d@web-ster.com...
>>> Bobby wrote:
>>>> Why is it important for a C compiler to be "ANSI compatible"? Does that
>>>> have any special
>>>> advantage with my code?
>>>>
>>> If you want your code to be portable, and if you want to hire 
>>> programmers
>>> to help you out without having to train them up on your particular 
>>> version
>>> of C, you want ANSI compatibility.
>>
>> That doesn't guarantee portability though, does it?
>>
> No, but it makes it a lot more possible.  With care you can write nice,
> portable code in ANSI standard C.  You can even make it talk to hardware
> with minimal work on the part of the user if you make well defined
> interfaces to driver code that takes care of all the non-portable bits.

Well yes, but you don't need ANSI C to do this.
And IME it is surprising (or perhaps its not) how many
engineering shops don't do this

tim

"tim....." wrote:
> "Tim Wescott" <tim@seemywebsite.com> wrote in message
>> Bobby wrote:
>>
>>> Why is it important for a C compiler to be "ANSI compatible"?
>>> Does that have any special advantage with my code?
>>
>> If you want your code to be portable, and if you want to hire
>> programmers to help you out without having to train them up on
>> your particular version of C, you want ANSI compatibility.
> 
> That doesn't guarantee portability though, does it?

It means your code, if properly written, will compile and run on
any system that meets the specifications of the ISO C standard. 
Things that are different can be identified immediately by
examining the content of <limits.h> (which is only about a dozen
values).  By avoiding "optional features" you ensure that things
are always defined.  This eliminates such beasts as 'uint8_t'
types.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer wrote:
> Things that are different can be identified immediately by
> examining the content of <limits.h> 

... only some of them.  To give just one potentially nasty example: 
nothing in <limits.h> (or any other standard library header file) tells 
you whether

	int a = -2; b = 3;
	
	printf("%d", a/b);

will print '-1' or '0'.  C99 states a requirement in this case, previous 
standards didn't.

Hans-Bernhard Br�ker wrote:
> CBFalconer wrote:
>
>> Things that are different can be identified immediately by
>> examining the content of <limits.h>
> 
> only some of them.  To give just one potentially nasty example:
> nothing in <limits.h> (or any other standard library header file)
> tells you whether
> 
>         int a = -2; b = 3;
>         printf("%d", a/b);
> 
> will print '-1' or '0'.  C99 states a requirement in this case,
> previous standards didn't.

Conceded.  I was thinking of things to do with type, not to do with
the particular standard in effect.

-- 
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



-- 
Posted via a free Usenet account from http://www.teranews.com

On Sep 12, 4:16 am, "Bobby" <bob2...@yahoo.com> wrote:
> "Tim Wescott" <t...@seemywebsite.com> wrote in message
>
> news:pt6dnZXBjouaeXvbnZ2dnUVZ_vHinZ2d@web-ster.com...
>
> > Bobby wrote:
> > > Why is it important for a C compiler to be "ANSI compatible"? Does that have any
> special
> > > advantage with my code?
>
> > If you want your code to be portable, and if you want to hire
> > programmers to help you out without having to train them up on your
> > particular version of C, you want ANSI compatibility.
>
> I thought that ANSI compatibility referred to the  _output_  of the C compiler?

No, ANSI compatibility here refers to being able to compile ANSI C
code. ANSI C is one of the standards that everybody (mostly)
recognise. So ANSI compatibility refers to the _input_ into the C
compiler.

Why is this important? Well, in the bad old days before
standardisation different compiler vendors have different ideas on how
C should behave and look like. So mastering UBERTECH C does not
necessarily mean you can write code for SUPER C. Worse, usually you
cannot compile code written for one compiler on another compiler.
Nobody knew which part of the language were common accross compilers
and which are vendor specific extensions.

Then ANSI came along and wrote a spec and said: well, THIS is ANSI C.
And vendors started to implement ANSI C. Which led to the happy
situation where any program written according to the ANSI C spec will
compile on any compiler supporting ANSI C without modification.
Weather the behavior of the resulting executable was what you expected
or not is a different issue. For example a program written to modify
VGA screen colors on a PC won't work on a Cisco router because
specific memory/register address written to point to different
hardware. But hey, at least it's compilable.

So it boils down to this: after learning C, do you want a compiler
that can simply compile the program you've written or do you want a
compiler that requires you to read its manual to figure out which
parts of "C" the compiler supports and which parts aren't implemented?
There are a lot of compilers out there especially in the embedded
market claiming to be "C" compilers but don't implement C according to
the ANSI specification. Of course they should really be called C-like
languages but marketing insist there's no noticeable difference.

On 2007-09-13, slebetman@yahoo.com <slebetman@gmail.com> wrote:
>
> Why is this important? Well, in the bad old days before
> standardisation different compiler vendors have different ideas on how
> C should behave and look like. So mastering UBERTECH C does not
> necessarily mean you can write code for SUPER C. Worse, usually you
> cannot compile code written for one compiler on another compiler.

It was worse than that: code for one non-standard compiler often
_would_ compile on another non-standard compiler without comment
but with a different interpretation introducing bugs that may or
may not be noticed in testing.  An example that comes to mind is
in the relational and logical operators.  ANSI C and some pre-standard
compilers forced the result to either 0 or 1, other simply returned
on or other of the parameters.  For example (a && b) could be
implemented as (a ? b : 0) instead of (a && b ? 1 : 0).

This could have an effect where the result of such an expression
is reused as a numeric rather than logical value.  An example of
this is (30 + (m < 8 != (m % 2))) which gives the number of days
in a non-February month.  Works fine in ANSI C.  Some pre-standard
compilers will have issues with it.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

"slebetman@yahoo.com" <slebetman@gmail.com> writes:
> On Sep 12, 4:16 am, "Bobby" <bob2...@yahoo.com> wrote:
> > "Tim Wescott" <t...@seemywebsite.com> wrote in message
> >
> > > Bobby wrote:
> > > > Why is it important for a C compiler to be "ANSI compatible"? Does that
> > > > have any special advantage with my code?
> >
> > > If you want your code to be portable, and if you want to hire
> > > programmers to help you out without having to train them up on your
> > > particular version of C, you want ANSI compatibility.
> >
> > I thought that ANSI compatibility referred to the  _output_  of the C compiler?
> 
> No, ANSI compatibility here refers to being able to compile ANSI C
> code. ANSI C is one of the standards that everybody (mostly)
> recognise. So ANSI compatibility refers to the _input_ into the C
> compiler.

Standardization of a computer programming language should get you to a
state where given a standard-conforming source program, you should be
able to compile it with any standard-conforming compiler and get code
which will produce the same output for given inputs that another
standard-conforming installation will get.  It doesn't do you much
good to have a compiler that will accept standard-conforming source
and generate code which will produce non-conforming output when
executed.  [We will stay away from a discussion as to how close to
identical things have to be for floating-point arithmetic.]

Andrew Smallshaw wrote:

> ...  An example that comes to mind is
> in the relational and logical operators.  ANSI C and some pre-standard
> compilers forced the result to either 0 or 1, other simply returned
> on or other of the parameters.  For example (a && b) could be
> implemented as (a ? b : 0) instead of (a && b ? 1 : 0).

Probably meant (a ? a : b)

Andrew Smallshaw wrote:

> ...  An example that comes to mind is
> in the relational and logical operators.  ANSI C and some pre-standard
> compilers forced the result to either 0 or 1, other simply returned
> on or other of the parameters.  For example (a && b) could be
> implemented as (a ? b : 0) instead of (a && b ? 1 : 0).

Probably meant (a ? a : b)

On Sep 14, 4:13 am, moja...@mojaveg.lsan.mdsg-pacwest.com (Everett M.
Greene) wrote:
> "slebet...@yahoo.com" <slebet...@gmail.com> writes:
> > On Sep 12, 4:16 am, "Bobby" <bob2...@yahoo.com> wrote:
> > > "Tim Wescott" <t...@seemywebsite.com> wrote in message
>
> > > > Bobby wrote:
> > > > > Why is it important for a C compiler to be "ANSI compatible"? Does that
> > > > > have any special advantage with my code?
>
> > > > If you want your code to be portable, and if you want to hire
> > > > programmers to help you out without having to train them up on your
> > > > particular version of C, you want ANSI compatibility.
>
> > > I thought that ANSI compatibility referred to the  _output_  of the C compiler?
>
> > No, ANSI compatibility here refers to being able to compile ANSI C
> > code. ANSI C is one of the standards that everybody (mostly)
> > recognise. So ANSI compatibility refers to the _input_ into the C
> > compiler.
>
> Standardization of a computer programming language should get you to a
> state where given a standard-conforming source program, you should be
> able to compile it with any standard-conforming compiler and get code
> which will produce the same output for given inputs that another
> standard-conforming installation will get.  It doesn't do you much
> good to have a compiler that will accept standard-conforming source
> and generate code which will produce non-conforming output when
> executed.  [We will stay away from a discussion as to how close to
> identical things have to be for floating-point arithmetic.]

Two things.

First, the OP said "_output_  of the C compiler". I read that as
literally the output of the C compiler: the executable program plus
any status, warning and error message. The output of the compiler is
therefore different depending on target architecture. It's even
different between C compilers of the same target architecture. Heck
it's even different using the same compiler but with different
optimisations enabled. The C standard in this case does not dictate
WHAT the output should be. It just says that the source code has
specific meanings which must be implemented by the generated output
program.

Secondly, even if the OP did misstate the sentence and really did mean
it as how you read it, the ANSI C standard is one of those standard
that doesn't specify the output of the generated program much. C is
very lenient in this regard (to the frustration of people wanting to
write robust portable code). For example when writing a char most
programs will write 8 bits of data. But there are compilers out there
that generate programs that treats char as 16 or even 32 bits. And
guess what? All of them conform to the standard! When it comes to C,
"standard conforming output" does not necessarily mean "the output
you'd expect" (of course, with experience, you'll learn to expect the
unexpected when using C).