Why is it important for a C compiler to be "ANSI compatible"? Does that have any special advantage with my code?
- posted
16 years ago
Why is it important for a C compiler to be "ANSI compatible"? Does that have any special advantage with my code?
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
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
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
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
That doesn't guarantee portability though, does it?
tim
any special
I thought that ANSI compatibility referred to the _output_ of the C compiler?
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!
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.
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
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
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.
... 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.
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.
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.
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
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.]
Probably meant (a ? a : b)
Probably meant (a ? a : b)
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).
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.