EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Whay is a C compiler ANSI compatible?

Started by Bobby September 11, 2007
"slebetman@yahoo.com" <slebetman@gmail.com> writes:
> 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.
I didn't interpret it that way since none of the standards say anything about the generated output of the compiler.
> 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.
Correct -- as it is with all programming language standards.
> 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).
You can expect to get a result of 2 if you say 1 + 1.
> 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).
The size of data types is a well-known area of implementation-defined behavior.
On Sep 15, 12:20 am, moja...@mojaveg.lsan.mdsg-pacwest.com (Everett M.
Greene) wrote:
> "slebet...@yahoo.com" <slebet...@gmail.com> writes: > > 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. > > I didn't interpret it that way since none of the standards say > anything about the generated output of the compiler. > > > 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. > > Correct -- as it is with all programming language standards. > > > 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). > > You can expect to get a result of 2 if you say 1 + 1. >
but what about: unsigned char x = 255; x++; The standard specifies that unsigned char rolls over when it reaches maximum but 255 isn't necessarily maximum. Here both 0 and 256 are valid outputs.
On Sep 11, 5:30 pm, "tim....." <tims_new_h...@yahoo.co.uk> wrote:
> "Tim Wescott" <t...@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" <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. > > >> 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- Hide quoted text - > > - Show quoted text -
there are a number of very good reasons, the mythical "well defined interfaces" requires knowledge of future products, results in very large complex code to handle all the different types of interfaces, increases testing costs, size of executable, results in "dead code" which is sometimes not allowable in meet certification requirements etc etc etc
Richard wrote:
> Andrew Smallshaw wrote:
>> For example (a && b) could be >> implemented as (a ? b : 0) instead of (a && b ? 1 : 0).
> Probably meant (a ? a : b)
No, he meant what he said, because he was talking about (a && b). Your suggestion doesn't work out for that. It would work for (a || b) instead. If you don't believe me, break out a pen and paper and work out the results for all combinations of a and b being either zero or three.
Hans-Bernhard Br&#4294967295;ker wrote:

> Richard wrote: > >> Andrew Smallshaw wrote: > > >>> For example (a && b) could be >>> implemented as (a ? b : 0) instead of (a && b ? 1 : 0). > > >> Probably meant (a ? a : b) > > > No, he meant what he said, because he was talking about (a && b). Your > suggestion doesn't work out for that. It would work for (a || b) > instead. If you don't believe me, break out a pen and paper and work > out the results for all combinations of a and b being either zero or three. >
It OK, I rite compilers. I made goof. No pen and papya needed. :-)
"Bobby" <bob2222@yahoo.com> writes:
> Why is it important for a C compiler to be "ANSI compatible"? > Does that have any special advantage with my code?
It depends. Is your code "ANSI compatible"?

Memfault Beyond the Launch