questions about C language dialects in Xcode and C standards in general

Hello. I've asked some of these questions in a previous thread, but I wanted to get some further information on them, and in the context of other questions I have. So, here goes...

From what I understand, besides K&R, which was more of a de facto standard before there was an official C standard, the first standard was established by ANSI and ratified in 1989, and became known as the C89 standard (commonly referred to as ANSI C). Then, a year later, in 1990, ISO adopted the standard, establishing what became known as the C90 standard (sometimes referred to as ISO C). Finally, almost a decade later, in 1999, ANSI readopted the ISO C90 standard, established the C99 standard, which is the current standard for the C language. This brings up a few questions:

First off, if you examine the options for the C Language Dialect setting in Project Settings in Xcode, you'll see a few choices: ANSI C, C89, GNU89, C99, GNU99, and Compiler Default. So...

1.) What's up with the Compiler Default option? Does this vary from system to system (could it be different on your computer than on mine)? Xcode always uses the same compiler (GCC, right?) no matter what computer it's on, so shouldn't the Compiler Default setting be the same on any computer? How's that work?

2.) There are two seemingly identical options: ANSI C and C89. Technically, of course, any ANSI C standard (C89 or C99) could be considered ANSI C, but specifically, the term ANSI C is used to refer to the C89 standard -- I've read from numerous sources ("Learn C on the Mac" is the one I have in front of me at the moment). So, then, what would be the difference between the ANSI C dialect option and the C89 dialect option?

3.) What's the deal with the ISO standard (C90) not being included in these options? Is it just similar enough to either C89 or C99 that they didn't feel it was necessary to include, or is there some other reason?

4.) With the exception of Compiler Default and the ANSI C options, each option has a GNU version. So, in addition to the C89 dialect option, they also have the GNU89 dialect option, and in addition to the C99 dialect option, they also have the GNU99 dialect option. These (GNU89 and GNU99) aren't actual established standards like C89 and C99, are they? I assume they are just options for the dialect. So, what are they? What's the difference between them and their C counterparts (GNU89 vs. C89 and GNU99 vs. C99)?

5.) How exactly do these options affect your project, or your code in specific. For example, I believe C++-style comments (the // comments) weren't brought into the C standard until C99. I think this is correct, but whether it is or not, let's assume it is for the sake of this question. So, I'm guessing that if I set the C Language Dialect option to C99 and try to use a C++ comment then all will be well, but if I set the option to C89 and try the same thing then I will get an error -- is this right? I would test it myself, but like I said, I'm not positive that I'm correct about C++ comments being introduced to the standard with C99. So, if this is right, then you'll be more restricted with your code by setting the option to C89 than you would be by setting it to C99, right? So if I wrote code with the option set to C99 and used some of the features of language that were added to the C standard with C99 and not before that, it would work fine, but if I then needed to give the code to someone else for them to edit it, and if they were using a compiler that used to original ANSI C (C89) standard, then they would get a bunch of errors and have to edit the code, right? For this reason, might it be a good idea for me to get in the habit of programming C with the language dialect option set to C89 (or ANSI C -- again, not sure why both are there or what the difference is).

So, that wraps up my questions about the C Language Dialect option, and there's only a few more things I wanted to ask about standards in general:

6.) I'm not really clear on exactly what a standard actually is or what it does in terms of the C language. When they establish a new standard for the C language, what exactly happens to the language? Does the language itself actually change? Do they change the built-in language elements (the syntax and structure and keywords and all that) to correspond to the new standard? Or is it more of just a declaration of how people are supposed to program C under the standard? I'm not sure if that made sense, but I just wanted to try to understand the nature of standards for the C language a little better and how, exactly, they contribute to or alter the language.

7.) Does anyone know if there's been any talk of a new standard, or are we going to be under the C99 standard for the foreseeable future? Being a more low-level language, maybe C is more self-sufficient and they don't feel the need to make changes to the languageOr maybe that makes no sense.

Sorry, guys -- I know this was a long one, and the issues I asked about aren't particularly important I guess, so I'm not really expecting anyone to give a comrehensive response answering all my questions in full detail -- just any input on anything here will be greatly appreciated. Thanks in advance!

8.) On that note,

MacBook, Mac OS X (10.5.8)

Posted on Dec 6, 2009 5:34 AM

Reply
12 replies

Dec 6, 2009 4:40 PM in response to Tron55555

Tron55555 wrote:
1.) What's up with the Compiler Default option?


Xcode is just an IDE. You can use whatever compiler you want in it.

Xcode always uses the same compiler (GCC, right?) no matter what computer it's on, so shouldn't the Compiler Default setting be the same on any computer?


Nope. As of Snow Leopard, Xcode has 3 C compilers - GCC, LLVM, and Clang. Don't get too comfortable with GCC, it is going away. You can also use Intel's compiler if you want (to pay for it).

2.) There are two seemingly identical options: ANSI C and C89. Technically, of course, any ANSI C standard (C89 or C99) could be considered ANSI C, but specifically, the term ANSI C is used to refer to the C89 standard -- I've read from numerous sources ("Learn C on the Mac" is the one I have in front of me at the moment). So, then, what would be the difference between the ANSI C dialect option and the C89 dialect option?


ANSI C is the latest ANSI C standard. Until 1999, ANSI C and C89 were the same, now they are not.

3.) What's the deal with the ISO standard (C90) not being included in these options? Is it just similar enough to either C89 or C99 that they didn't feel it was necessary to include, or is there some other reason?


C89 was just an ANSI standard. C90 is also an international (ISO) standard.

4.) With the exception of Compiler Default and the ANSI C options, each option has a GNU version. So, in addition to the C89 dialect option, they also have the GNU89 dialect option, and in addition to the C99 dialect option, they also have the GNU99 dialect option. These (GNU89 and GNU99) aren't actual established standards like C89 and C99, are they? I assume they are just options for the dialect. So, what are they? What's the difference between them and their C counterparts (GNU89 vs. C89 and GNU99 vs. C99)?


That's a long story: http://gcc.gnu.org/c99status.html

5.) How exactly do these options affect your project, or your code in specific. For example, I believe C++-style comments (the // comments) weren't brought into the C standard until C99. I think this is correct, but whether it is or not, let's assume it is for the sake of this question. So, I'm guessing that if I set the C Language Dialect option to C99 and try to use a C++ comment then all will be well, but if I set the option to C89 and try the same thing then I will get an error -- is this right? I would test it myself, but like I said, I'm not positive that I'm correct about C++ comments being introduced to the standard with C99.


Why not test it yourself?

So, if this is right, then you'll be more restricted with your code by setting the option to C89 than you would be by setting it to C99, right? So if I wrote code with the option set to C99 and used some of the features of language that were added to the C standard with C99 and not before that, it would work fine, but if I then needed to give the code to someone else for them to edit it, and if they were using a compiler that used to original ANSI C (C89) standard, then they would get a bunch of errors and have to edit the code, right?


Correct.

For this reason, might it be a good idea for me to get in the habit of programming C with the language dialect option set to C89 (or ANSI C -- again, not sure why both are there or what the difference is).


It depends. If you are writing BSD-only code it might be a good idea to stay compatible. If you are writing Cocoa code, don't worry about it. You can always use C++ too. If you don't use any objects, C++ from 1989 is very similar to C from 1999.

6.) I'm not really clear on exactly what a standard actually is or what it does in terms of the C language. When they establish a new standard for the C language, what exactly happens to the language? Does the language itself actually change? Do they change the built-in language elements (the syntax and structure and keywords and all that) to correspond to the new standard? Or is it more of just a declaration of how people are supposed to program C under the standard? I'm not sure if that made sense, but I just wanted to try to understand the nature of standards for the C language a little better and how, exactly, they contribute to or alter the language.


When a new standard is official released, compiler vendors are supposed to make changes to their compilers to support the new standard. Sometimes they do, sometimes they don't. Only one vendor has ever fully implemented the C++ standard, for example. It is an exercise in herding cats.

7.) Does anyone know if there's been any talk of a new standard, or are we going to be under the C99 standard for the foreseeable future? Being a more low-level language, maybe C is more self-sufficient and they don't feel the need to make changes to the languageOr maybe that makes no sense.


There will always be academics wanting to incorporate their dissertation topic in the standard. There will also always be companies wishing to make special features in their compilers part of the new standard. I expect this will continue forever.

Dec 6, 2009 11:19 PM in response to Tron55555

Regarding the C lanuage standard, if you look at the standard itself you wil see that it falls apart in two parts: one is the language proper and and one is the library.

The C langauge itself is defined in such a way that it "executes" on an abstract machine. The abstract machine is able to execute C source code directly. During the standardization effort great care was taken taken that a) the resulting standard language was/is backward compatible with existing C language programs and b) a standard conforming compiler (translator) can be implemented for as many real machines as possible.

The library part (chapter 7 of the standard) can be considered not a real part of the C language itself, i.e. if you do not use any of those functions, you still have a standard confirming application. Replacing the functions in the library with you own ones of course limits portability of you application.

Most current work on the standard seems to be extensions wrt. embedded systems (doing direct I/O), fixed point arithmetic (for DSPs), character sets and pointers (for allowing applications to be translated into better parallel code).

Another activity is the issueing of "technical corrigenda" which are basically corrections of defencies in the language definition.

Wrt. to the choice of a standard (C89 or C99): pick the one you need. C89 is of course very widely available and gives you maximum portability, while C99 adds a number of useful features such as booleans, complex numbers and such. Use it if you need them. When using compiler specific extensions (e.g. GNU C _attribute_) wrap them in <t> #define</t>s so you can easily change them when moving to a different compiler.

For more information on the standard itself and the activities around it go to the source:
http://www.open-std.org/JTC1/SC22/WG14/

With kind regards,
Hans

Dec 7, 2009 2:55 AM in response to etresoft

Xcode is just an IDE. You can use whatever compiler you want in it.


Okay, that makes sense, although clearly I didn't know that before. I mean, I knew Xcode was an development environment, not a compiler, but I guess I always just thought of it as one since I thought it had to use GCC.

Nope. As of Snow Leopard, Xcode has 3 C compilers - GCC, LLVM, and Clang. Don't get too comfortable with GCC, it is going away. You can also use Intel's compiler if you want (to pay for it).


Ahhh! Just when I'm getting used to it. Oh well. Would you recommend Intel's compiler? Are there any advantages for a simple soul like myself?

ANSI C is the latest ANSI C standard. Until 1999, ANSI C and C89 were the same, now they are not.


So then, now ANSI C is identical to C99? I would still have the same question about why it is there if it is identical to another option. Unless the point is that the ANSI C option will change as the current standard changes, although it seems a bit unnecessary if it will only matter once every ten years.

C89 was just an ANSI standard. C90 is also an international (ISO) standard.


Yeah I understood that, but I'm still not getting why they didn't include C90. Are you saying it was because C90 is ISO? Do they not include ISO standards? Why is that?

That's a long story: http://gcc.gnu.org/c99status.html


Okay -- I will check into that long story. Many thanks for the link.

Why not test it yourself?


I actually tried to answer that in my post ("I would test it myself, but like I said, I'm not positive that I'm correct about C++ comments being introduced to the standard with C99" -- me). In other words, they could have both not worked, and that could have only been because I was wrong about C++ comments not being added to the standard until 1999. I'm sure I can look that up somewhere, though (I tried briefly before the last post, but I guess not enough).

It depends. If you are writing BSD-only code it might be a good idea to stay compatible. If you are writing Cocoa code, don't worry about it. You can always use C++ too. If you don't use any objects, C++ from 1989 is very similar to C from 1999.


Okay -- good explanation. Without taking much more of your time, what is BSD-only code?

When a new standard is official released, compiler vendors are supposed to make changes to their compilers to support the new standard. Sometimes they do, sometimes they don't. Only one vendor has ever fully implemented the C++ standard, for example. It is an exercise in herding cats.


Okay -- perfect explanation. Thanks a lot, et -- that really cleared that up for me, and it's something I'd been unclear about for awhile. "an exercise in herding cats" -- hehe, I like that.

There will always be academics wanting to incorporate their dissertation topic in the standard. There will also always be companies wishing to make special features in their compilers part of the new standard. I expect this will continue forever.


Okay.

Thanks for a wonderful post, et. Short of the few notes above, you answered all my questions -- much appreciated.

P.S. -- hansz, I read your post as well. It was excellent. Thank you very much for the detailed explanation -- it cleared up a lot. Very much appreciated!

Dec 7, 2009 9:29 AM in response to Tron55555

Tron55555 wrote:
Oh well. Would you recommend Intel's compiler?


Yes. The chip vendor's supported compiler is almost always going to be better than some open-source version. Of course, it costs about $500 I think.

Are there any advantages for a simple soul like myself?


Not really.

So then, now ANSI C is identical to C99?


C99 is ANSI C, but "-std=c99" is not "-ansi" and never will be. The "-ansi" command line option is a new one back when both GCC and ANSI were, themselves, new. Now that "-ansi" has been used there is legacy code that depends on that syntax and the option string can't be changed.

Yeah I understood that, but I'm still not getting why they didn't include C90. Are you saying it was because C90 is ISO? Do they not include ISO standards? Why is that?


They could have added a "-std=c90" option and made it identical to "-std=c89" if they wanted to. I don't know why they didn't.

I actually tried to answer that in my post ("I would test it myself, but like I said, I'm not positive that I'm correct about C++ comments being introduced to the standard with C99" -- me). In other words, they could have both not worked, and that could have only been because I was wrong about C++ comments not being added to the standard until 1999. I'm sure I can look that up somewhere, though (I tried briefly before the last post, but I guess not enough).


Don't look it up, test it.

#include <stdio.h>
int main(void)
{
// This is a comment.
return 0;
}

gcc -std=c89 test.c
gcc -std=c99 test.c
gcc test.c

Okay -- good explanation. Without taking much more of your time, what is BSD-only code?


Code that doesn't use Cocoa, Carbon, Core Foundation, etc. BSD is code that you will find on any UNIX or *nix OS. The other stuff is only on the Mac (more or less). Being new to both worlds, it may be more difficult for you to see the difference at this time.

Dec 7, 2009 11:46 AM in response to etresoft

To be pedantic (pun intended)...
Don't look it up, test it.

#include <stdio.h>
int main(void)
{
// This is a comment.
return 0;
}

gcc -std=c89 test.c
gcc -std=c99 test.c
gcc test.c



cc -std=c89 -pedantic -fsyntax-only test.c
$ cc -std=c89 -pedantic -fsyntax-only test.c
std.c: In function ‘main’:
std.c:5: error: syntax error before ‘/’ token
$ cc -std=c99 -pedantic -fsyntax-only test.c


From man gcc:


-pedantic
Issue all the warnings demanded by strict ISO C and ISO C++; reject
all programs that use forbidden extensions, and some other programs
that do not follow ISO C and ISO C++. For ISO C, follows the
version of the ISO C standard specified by any -std option used.
...
Some users try to use -pedantic to check programs for strict ISO C
conformance. They soon find that it does not do quite what they want:
it finds some non-ISO practices, but not all---only those for which
ISO C requires a diagnostic, and some others for which diagnostics
have been added.
...


gcc is quite lenient wrt. to C syntax and mostly rightly so which is why gcc -std=c89 test.c does not complain about //. (Note that the previous statement does not endorse the use of // for commenting code 😉 ).

With kind regards,
Hans

Dec 7, 2009 1:01 PM in response to hansz

In addition to // comments, there is another big thing that you get in C99 and C++: you can declare your variables where you want. Instead of doing something like:

int i;
for(i = 0; i < 10; ++i)
{
int j;
int k;
int q;
// do something with j.
// do something with k.
// do somethign with q.
}

you can do:

for(int i = 0; i < 10; ++i)
{
// do something with j.
int j;
// do something with k.
int k;
// do somethign with q.
int q;
}


I used to be stuck in C89 thinking and always used either C++ or Objective-C++ just to get this feature. Then someone happened to ask why I did that and I had to re-evaluate.

Objective-C is so easy to get things done that I really don't need to use C++ anymore. If I didn't have Objective-C, I would use C++. Of course, that is assuming I can't use Perl, which would be my first non-Objective-C preference.

Dec 8, 2009 4:19 AM in response to etresoft

hansz -- thanks for your code. It helped to clear some things up for me -- much appreciated.

for etresoft:

C99 is ANSI C, but "-std=c99" is not "-ansi" and never will be. The "-ansi" command line option is a new one back when both GCC and ANSI were, themselves, new. Now that "-ansi" has been used there is legacy code that depends on that syntax and the option string can't be changed.


So then what is the difference between "-std=c99" and "-ansi"? I guess what I'm asking is, if the "-std=c99" option represents the C99 standard and the "-ansi" options represents the ANSI C standard, and if C99 is ANSI C, then what differences would there be between the two options? Why would someone set there project settings to one over the other? Don't spend to much time answering this, if any. It's not important at the moment for me -- I'm just curious.

They could have added a "-std=c90" option and made it identical to "-std=c89" if they wanted to. I don't know why they didn't.


Oh, so then the ANSI C89 standard and the ISO C90 standard are identical in terms of their changes to the language and whatnot? I think that's what I didn't undestand. For example, C99 added things to the language that C90 didn't have, so I assumed C90 added things to the language that C89 didn't have.

Code that doesn't use Cocoa, Carbon, Core Foundation, etc. BSD is code that you will find on any UNIX or *nix OS. The other stuff is only on the Mac (more or less). Being new to both worlds, it may be more difficult for you to see the difference at this time.


So BSD refers to anything that is not specific to Mac (like the Cocoa or Carbon frameworks or Core Foundation and whatnot, like you said). Okay, that helps me understand what you were saying in your last post better. Thanks.

In addition to // comments, there is another big thing that you get in C99 and C++: you can declare your variables where you want. Instead of doing something like:


Yeah I'm familiar with that change from C99, but I'm curious about exactly how it worked. I know you had to declare your variables at the beginning before C99, but at the beginning of what? Every block of code? Is that right? Wow, I'm glad they changed that. I could see that being inconvenient.

Dec 8, 2009 7:25 AM in response to Tron55555

Tron55555 wrote:
So then what is the difference between "-std=c99" and "-ansi"?


"-ansi" is forever limited to C89. When C89 came out, it wasn't C89, it was just "ANSI". It didn't become C89 until something else came out to differentiate it.

Why would someone set there project settings to one over the other?


I think that is a very important question. Sometimes people write code assuming very minute and specific parts of a language - things an ordinary programmer would never know without studying (and I mean studying) the standard. Such code would break or return a different result if those very obscure parts of the language were to ever change. Now, you could write code that didn't depend on such details and would compile on virtually any version of the language. There is a difference between "good" code and "legal" code.

I assumed C90 added things to the language that C89 didn't have.


Nope. Just a different committee. Well, it was a committee composed of about the same people, but they met in Copenhagen in 1990 instead of Chicago in 1989.

I know you had to declare your variables at the beginning before C99, but at the beginning of what? Every block of code? Is that right?


Yes, but people normally only put them at the beginning of each function. They still do that today.

Dec 8, 2009 12:02 PM in response to etresoft

"-ansi" is forever limited to C89. When C89 came out, it wasn't C89, it was just "ANSI". It didn't become C89 until something else came out to differentiate it.


hehe I'm missing something here. So then what's the difference between "-std=c89" and "-ansi"? I'm just not understanding what the need is for the "-ansi" option when you already have C89 and C99 options, which are the only two ANSI standards. What is the need for both "-ansi" and "-std=c89" if they are the same? I really just want to know if there are any differences in the way my project will behave when it is set to "-ansi" versus when it is set to "-std=c89".

Nope. Just a different committee. Well, it was a committee composed of about the same people, but they met in Copenhagen in 1990 instead of Chicago in 1989.


Okay -- I see now. That's what was confusing me there, so thanks for helping me to clear that up.

Yes, but people normally only put them at the beginning of each function. They still do that today.


Really? That's interesting. I thought it was supposed to be most efficient to declare a variable within the smallest scope possible. So, you're saying even if a variable was never going to be used outside a certain "if" construction, I should still declare it at the beginning of the function?

Dec 8, 2009 12:26 PM in response to Tron55555

Tron55555 wrote:
So then what's the difference between "-std=c89" and "-ansi"?


None. It is just that "-ansi" was added to GCC first. Lots of people used it. Then C99 rolled around. If they had changed the meaning of the old "-ansi" it would break lots of code. So, they added "-std=c89" and "-std=c99", among others. So, if you aren't up on current affairs, but still want to use ANSI standards, use "-ansi". If you do know what C99 is, but your boss won't let you use it, use "-std=c89" instead of "-ansi" to shout out to the world (i.e. the 2 other people who will ever see your code) that you used the old C89 standard on purpose and that they can make of that what they will.

Really? That's interesting. I thought it was supposed to be most efficient to declare a variable within the smallest scope possible.


It is ever so slightly more efficient wait to create the variable until you have a decent value to initialize it with. You may be able to skip a useless initialization step. It is better for code readability to have variables initialized closer to where they are used - in my opinion, at least.

So, you're saying even if a variable was never going to be used outside a certain "if" construction, I should still declare it at the beginning of the function?


No. I said "people" and that implied "people whose coding styles I disdain".

Dec 8, 2009 12:51 PM in response to etresoft

None. It is just that "-ansi" was added to GCC first. Lots of people used it. Then C99 rolled around. If they had changed the meaning of the old "-ansi" it would break lots of code. So, they added "-std=c89" and "-std=c99", among others. So, if you aren't up on current affairs, but still want to use ANSI standards, use "-ansi". If you do know what C99 is, but your boss won't let you use it, use "-std=c89" instead of "-ansi" to shout out to the world (i.e. the 2 other people who will ever see your code) that you used the old C89 standard on purpose and that they can make of that what they will.


Excellent. That's the answer I was looking for. Thanks, et -- that cleared that right up.

It is ever so slightly more efficient wait to create the variable until you have a decent value to initialize it with. You may be able to skip a useless initialization step. It is better for code readability to have variables initialized closer to where they are used - in my opinion, at least.


Okay -- makes sense. I've always declared my variables in the closest scope I can, so I think I'll continue to do so.

No. I said "people" and that implied "people whose coding styles I disdain".


Ah, gotcha. 🙂

Thanks for all your help everyone -- very much appreciated!

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

questions about C language dialects in Xcode and C standards in general

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.