Whay is a C compiler ANSI compatible?

Why is it important for a C compiler to be "ANSI compatible"? Does that have any special advantage with my code?

Reply to
Bobby
Loading thread data ...

Why is it important for you language to be English compatible when speaking to a unilingual Anglophone?

Think about using multiple compilers from multiple vendors targeted at multiple architectures and using multiple tools to generate, edit and analyze the code over multiple projects. Conversely, consider if you only use a single compiler with no associated tools only targeted at a single architecture then do you even care if it's a C compiler? If you do what defines whether it is C or not?

Assuming, of course, you are not wanting to get into a discussion of ISO/ANSI and the differences between the latest and previous standards.

How long is a piece of string?

Robert

Reply to
Robert Adsett

So you can honestly call it a "C compiler."

If you write ANSI compatible code it does: it means the compiler can compile your code. A compiler that can't compile your code is a waste of bits.

--
Grant Edwards                   grante             Yow! Here we are in America
                                  at               ... when do we collect
 Click to see the full signature
Reply to
Grant Edwards

any special

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.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

And if your code may some day have to withstand the scrutiny of agencies such as FDA or FAA it might become even more important.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

That doesn't guarantee portability though, does it?

tim

Reply to
tim.....

any special

I thought that ANSI compatibility referred to the _output_ of the C compiler?

Reply to
Bobby

It does in so much as it specifies the behavior of a compiled program for a given input.

--
Grant Edwards                   grante             Yow! Everybody gets free
                                  at               BORSCHT!
 Click to see the full signature
Reply to
Grant Edwards

Depends on how strictly your code limits itself to ANSI compliance.

The important case is the opposite one, though: code not compliant to ANSI standards is effectively guaranteed to be non-portable.

Reply to
Hans-Bernhard Bröker

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.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
tim.....

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 (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.
Reply to
CBFalconer

... only some of them. To give just one potentially nasty example: nothing in (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.

Reply to
Hans-Bernhard Bröker

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.
Reply to
CBFalconer

have any

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.

Reply to
slebetman

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
Reply to
Andrew Smallshaw

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.]

Reply to
Everett M. Greene

Probably meant (a ? a : b)

Reply to
Richard

Probably meant (a ? a : b)

Reply to
Richard

compiler?

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).

Reply to
slebetman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.