Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is C99 backward compatible with C89?

Tags:

c

c99

I'm used to old-style C and and have just recently started to explore c99 features. I've just one question: Will my program compile successfully if I use c99 in my program, the c99 flag with gcc and link it with prior c99 libraries?

So, should I stick to old C89 or evolve?

like image 545
kar Avatar asked Nov 16 '09 01:11

kar


People also ask

What is the difference between C89 and C99?

In C89, the results of / and % operators for a negative operand can be rounded either up or down. The sign of i % j for negative i or j depends on the implementation. In C99, the result is always truncated toward zero and the sign of i % j is the sign of i. In C89, declarations must precede statements within a block.

Should I use C99 or C11?

It is best to use C11 as that is the current standard. C99 and C11 both contained various "language bug fixes" and introduced new, useful features.

Should I learn C89?

There is no reason to learn C89 or C90 over C99- it's been very literally superseded. It's easy to find C99 compilers and there's no reason whatsoever to learn an earlier standard. This doesn't mean that your professor won't force C89 upon you.

Is C backwards compatible?

C standards are not backward compatible - code written under the latest standard is not guaranteed to build with compilers that only support earlier versions.


2 Answers

I believe that they are compatible in that respect. That is as long as the stuff that you are compiling against doesn't step on any of the new goodies. For instance, if the old code contains enum bool { false, true }; then you are in trouble. As a similar dinosaur, I am slowly embracing the wonderful new world of C99. After all, it has only been out there lurking for about 10 years now ;)

like image 113
D.Shawley Avatar answered Oct 06 '22 12:10

D.Shawley


You should evolve. Thanks for listening :-)

Actually, I'll expand on that.

You're right that C99 has been around for quite a while. You should (in my opinion) be using that standard for anything other than legacy code (where you just fix bugs rather than add new features). It's probably not worth it for legacy code but you should (as with all business decisions) do your own cost/benefit analysis.

I'm already ensuring my new code is compatible with C1x - while I'm not using any of the new features yet, I try to make sure it won't break.

As to what code to look out for, the authors of the standards take backward compatibility very seriously. Their job was not ever to design a new language, it was to codify existing practices.

The phase they're in at the moment allows them some more latitude in updating the language but they still follow the Hippocratic oath in terms of their output: "first of all, do no harm".

Generally, if your code is broken with a new standard, the compiler is forced to tell you. So simply compiling your code base will be an excellent start. However, if you read the C99 rationale document, you'll see the phrase "quiet change" appear - this is what you need to watch out for.

These are behavioral changes in the compiler that you don't need to be informed about and may be the source of much angst and gnashing of teeth if your application starts acting strange. Don't worry about the "quiet change in c89" bits - if they were a problerm, you would have already been bitten by them.

That document, by the way, is an excellent read to understand why the actual standard says what it says.

like image 43
paxdiablo Avatar answered Oct 06 '22 13:10

paxdiablo