What C99 features are considered harmful or unsupported [closed]

Question

I usually write C code in C89, now some features of C99 (like intxx_t or __VA_ARGS__ or snprintf) are very useful, and can be even vital.

Before I more my requirements from C89 to C99 I wanted to know which of C99 features were widely supported and which ones were not widely supported or even considered harmful.

I know we could just check our target compiler support, but this would narrow our support a lot, and as this is for open source software, I'd prefer having a wider support.

For example, we use Solaris (suncc) compiler and gcc, but there might be other compiler we would move out of the way while we could keep compatibility with very little efforts.

For example, I never worked on Windows nor I know anything about Windows compilers, but it would be good to keep Windows compatibility.

Answer 1

A number of C99 features are optional, so their lack isn't technically non-conforming. I won't distinguish below.

• Hmm, win doesn't have <stdint.h>, although there is an open-source version of stdint.h for Microsoft. Even when the file is implemented, many of the individual types are missing.

• Complex and imaginary support is often missing or broken.

• Extended identifiers and wide characters can be problem points.

See this list of C99 feature issues in gcc.

Answer 2

goto is still considered harmful.

---

Somehow I have collected four down votes. I presented the statement above to add levity, and am only 30% serious about the concept behind it.

I expect the down votes are from youngsters who do not understand the history of programming languages. Not every single goto is evil, but–compared to 100% unadulterated spaghetti code I have worked on (millions of lines of FORTRAN 66)–it is reasonable and productive to replace as many goto statements with structured statements (for, while, do .. while, switch) as possible. But sometimes a goto is just fine when it avoids complexity, such as extra flag variables to break out of multiple nested loops.

Answer 3

Well, gcc is basically going to be gcc regardless of which desktop OS you're targeting.

Visual C++, being primarily a C++ compiler, isn't quite as concerned with the C99 spec. stdint.h does declare your favorite intxx_t macros. __VA_ARGS__ is available. _Bool, _Complex, and _Pragma aren't implemented on the Microsoft Visual C++ compiler. I'm pretty sure %a fields in printf/scanf haven't been implemented, though maybe VC2010 handles them. snprintf is present, but has a leading underscore and slightly different semantics.

Short answer: The "easier" a C99 feature is to implement without changing compiler grammars or replumbing the standard library, the more likely VC++ is to support it. If there's a conflict between C99 and C++, expect C++ to win.

Answer 4

Runtime sizeof is a nightmare of compiler's writers. So I consider is harmful.

Answer 5

glibc does not implement a C99-conforming realloc, so realloc(ptr, 0) is not portable.

http://sourceware.org/bugzilla/show_bug.cgi?id=12547

Answer 6

restrict became a keyword in C99. That is implementation encroaching on users' namespace. If you have a valid C89 program that contains the word restrict, you must change your program to make it work with C99. In other words: no backward compatibility. If they were going to break backward compatibility, they should have removed gets from the standard first.

Answer 7

The type generic maths functions from <tgmath.h> are not necessarily widely implemented, though they do seem to be provided with GCC 4.2.1 on MacOS X 10.6.2.