14

C99 adds several useful features to the language, yet I find it difficult to recommend any practice which depends upon C99. The reason for this is because there are few (any?) actual implementations of the C99 language. Sure, there is limited support in a few compilers, but nobody wants spend the time to write C code only to have it be unportable.

This is frustrating given that the standard was written and finalized over 10 years ago now. Plus I hear discussions of a C1x from time to time, and I wonder why someone would be taking steps to revise the language given that the current version of the language isn't yet implemented.

So my question is, as joe blow C programmer today, what is useful w.r.t. the C99 standard to me (if any)?

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • 1
    Like bypasses, you've got to build standards, I guess. But gcc actually tries to get closer to implementing C99, unlike MSVC. – Pascal Cuoq Nov 21 '10 at 23:43
  • 1
    @Pascal: I find it hard to believe that support of C99 is high on the developers of GCC's priority list given that they've had ten years and still major portions of the new standard are not yet implemented. – Billy ONeal Nov 21 '10 at 23:45
  • 2
    @Billy The current C99 revision is from 2007. – Šimon Tóth Nov 21 '10 at 23:47
  • @Let_Me_Be: There have been some technical reports, but the base parts of the language didn't change much (at all?) in those revisions. – Billy ONeal Nov 21 '10 at 23:48
  • 1
    @Billy That depends on what you consider "base parts". Plus the amount of changes in the standard doesn't have any relation to compiler code changes required. – Šimon Tóth Nov 21 '10 at 23:52
  • Related: [Why do new C books not adhere to the C99 standard?](http://stackoverflow.com/q/2303502/2509). – dmckee --- ex-moderator kitten Nov 22 '10 at 02:05
  • 3
    All of the popular C compilers support C99 to some extent except for MSVC – JeremyP Nov 22 '10 at 13:20

6 Answers6

14

C99 brings features that really makes programming in C easier and more error safe:

  • designated initializers
  • compound literals
  • for-scope variables
  • fixed width integer types

The language is also much more expressive with

  • variadic macros
  • inline functions

On my linux machine I have four compilers that support C99 to a satisfying extent that make this usable on a daily base: gcc, clang, opencc and icc.

The first two are open source compilers where clang trying to be code compatible to gcc (meaning C99 support is about the same).

The later two are from the two major CPU producers and are commercial but with generous license policy for non commercial users. Their C99 is a bit less, in particular their support for inline seems not completely consistent with the standard, yet.

Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177
  • Care to link to opencc's canonical website? – Matt Joiner Nov 22 '10 at 13:53
  • Does the Windows version if `icc` support C99? – Billy ONeal Nov 23 '10 at 16:45
  • @Billy, I don't use windows so I don't know for sure. But it would be surprising if it wouldn't, at least for the language itself. The C library support might be a different point, though. – Jens Gustedt Nov 23 '10 at 17:43
  • Do compound literal lvalues of automatic storage duration make the language safer and more expressive? Compound literal rvalues are a nice addition, and constant compound literals of static duration would be nice, but the uncontrollably-brief lifetime of compound literal lvalues makes them seem far less error safe than would be manually-created variables. – supercat Jul 25 '15 at 21:01
  • @supercat, compound literals have at least the lifetime that a variable that is declared just before the expression would have. This is not the same as C++'s temporaries, which are bound to the expression. They are bound to the scope, just like other objects. – Jens Gustedt Jul 25 '15 at 22:50
  • @JensGustedt: If one declares a variable immediately before a statement and then needs to move the statement into a nested scope (e.g. to make it be controlled by an `if` statement) one can still keep the variable outside that scope. I know of no way to do that with a compound literal except to create a new variable of the appropriate type outside the new scope and initialize it suitably (which wouldn't require a compound literal). – supercat Jul 26 '15 at 00:55
8

MSVC does not, nor will it probably ever, support C99. But Microsoft has little incentive to update their C compiler. It's not like they will lose much business over it.

But there are plenty of compilers that have support for C99.

http://en.wikipedia.org/wiki/C99#Implementations

Regarding gcc:

http://gcc.gnu.org/c99status.html

You are right that perhaps C99 is not useful for library code (and may never be without Microsoft's support), but if you're working on an in-house or personal project where you can pick the compilers and tools, then the portability is not much of an issue.

Matthew
  • 47,584
  • 11
  • 86
  • 98
  • 2
    +1 for an answer that actually answers my question rather than arguing with me. – Billy ONeal Nov 21 '10 at 23:58
  • 5
    @Billy Well, noone is arguing with the fact that MSVC doesn't support C99. If that is what you wanted to hear, you should have reformulated the question. – Šimon Tóth Nov 22 '10 at 00:22
  • 2
    MS will support C99 features once the new C++ standards officially incorporate many of them. They don't care about C but they don't want to be left behind in the C++ world. – R.. GitHub STOP HELPING ICE Nov 22 '10 at 00:34
  • 2
    @R, does MSVC support mixing declarations and code when compiling C code? It didn't the last time I used it (been a while) despite it being something that is allowed in C++. My larger question: has Microsoft actually claimed they would be adding overlapping features to the C compiler or is it just assumed? – Matthew Nov 22 '10 at 00:58
  • @Let_Me_Be: That's not what I was looking for at all. I'm looking for a "when should I use C99 features, and which ones should I use, if I care at all about portability". I.e. "What parts of the fact that this is a standard are useful to me as joe blow C programmer?" Yes, I know msvc doesn't support C99 -- I didn't need to ask a question here to find that out. I am checkmarking this answer for the last paragraph -- namely the "not useful for library code, but plenty useful for anything else" bit. – Billy ONeal Nov 23 '10 at 16:43
  • 3
    @Billy You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably). And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course). – Šimon Tóth Nov 23 '10 at 16:49
  • @Let_Me_Be: Thank you. Now would you pit that in your answer so I can upvote it? :) – Billy ONeal Nov 23 '10 at 16:51
7

Regarding C1x, I think it's worth noting that the standards committee is well aware that C99 has not been widely adopted and doesn't want to repeat the same mistakes (or to make the situation worse). From the C1x charter:

Unlike for C9X, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the Standard and the commercial implementation compatible.

And:

The original standard had a very positive reception from both the user and vendor communities. However, C99 has been not so widely received.

jamesdlin
  • 81,374
  • 13
  • 159
  • 204
  • 4
    I find it hard to take these statements seriously when they're considering adopting all those useless MS functions which were created to derail C and portability - functions which nobody else wants to support. – R.. GitHub STOP HELPING ICE Nov 22 '10 at 00:37
  • 5
    @R..: If you're referring to the various "safe" versions of the string functions, I think that they're a good thing. (Or they can alternatively go with `strlcpy` and `strlcat`; I don't care.) By definition, inventing any extension "derails portability", but the point of incorporating one into the standard is to fix that. Also, if it means that Microsoft might actually want to get on board with C1x, that would be great. – jamesdlin Nov 22 '10 at 05:38
  • IMHO, rather than saying "no invention", a better tack would be to specify features which could be emulated on existing compilers via macros, but could work better with support from new compilers (e.g. standard-defined macros for things like "rotate right" and "rotate left", which could be emulated via call to (hopefully) inline function, but could also be expand to compiler intrinsics. If `x` and `y` are a "simple variables", `(x>>y) | (x >> (31-y) >> 1)` will likely translate to a nasty sequence of instructions, `__rotright(x,y)` would more likely be able to yield a single instruction. – supercat Jul 25 '15 at 20:59
4

You should use C99 whenever you are not locked in an environment that doesn't support C99 (embeded systems most notably).

And yes, if you know that your library will be used by people that are using MSVC, you can't use C99 features in the interfaces, but there is no reason not to use C99 in the implementation (apart from library feature dependencies of course).

Original answer: "Uh? What compilers don't support C99? Plus when you move from compilers to tools, C99 is actually more commonly supported then C89."

Šimon Tóth
  • 35,456
  • 20
  • 106
  • 151
  • 4
    I don't know of any compilers which support C99. Neither GCC nor MSVC do, and these are the only compilers I've dealt with on a regular basis. – Billy ONeal Nov 21 '10 at 23:39
  • 2
    @Billy Well, if you consider this state unsupported http://gcc.gnu.org/c99status.html then I guess you can't really code in anything :-) As soon as a standard is "supported" it is already deprecated. MSVC actually officially supports C? – Šimon Tóth Nov 21 '10 at 23:43
  • 1
    According to that page it's missing most everything useful in `wctype.h` and `stdint.h`. I'm not 110% familiar with the other missing stuff, but those are big pieces of functionality that are not there. – Billy ONeal Nov 21 '10 at 23:47
  • @Billy You should probably read the whole page. Specifically the "Further notes" part. – Šimon Tóth Nov 21 '10 at 23:49
  • @Let_Me_Be: Regardless, even if one could call the state of GCC's support of C99 "supporting C99", that's still only a single compiler. (And I don't see anything in the "further notes" segment there which changes what I said earlier) If I wanted to be limited to a single compiler I wouldn't bother with standards at all and use compiler specific bits instead (i.e. `std=gnu99`, etc) – Billy ONeal Nov 21 '10 at 23:54
  • I think the option to declare variables within the scope of a for-loop and VLAs are extremely useful. But then, I don't code C on a regular basis :-). – helpermethod Nov 21 '10 at 23:55
  • @Helper Method: Did I ever say they were **not** useful? – Billy ONeal Nov 21 '10 at 23:56
  • 2
    I think you need to back up your claim that "C99 is actually more commonly supported than C89." – jamesdlin Nov 22 '10 at 00:01
  • Note: I did not downvote this answer. I think some of the comments here are constructive even if the answer itself is not (Therefore I won't upvote the answer, but I'm not going to downvote it either) – Billy ONeal Nov 22 '10 at 00:05
  • 1
    @Billy ONeal: I believe that all that is "missing" for `wctype.h` is the wide character format string checking, which isn't specified by C99 anyway - it's just a "nice to have". `stdint.h` is only missing on "some platforms". – caf Nov 22 '10 at 01:01
2

If you care for performance, there's no way around restrict.

Christoph
  • 164,997
  • 36
  • 182
  • 240
1

FreeBSD is now using Clang for kernel compiles and that pretty much supports C99.

Rob
  • 14,746
  • 28
  • 47
  • 65