What features of the C99 are considered harmful or unsupported

Question

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

Before I became more of my requirement from C89 to C99, I wanted to know which of the C99 functions were widely supported and which of them were not widely used or even considered harmful.

I know that we could just test our support for the target compiler, but that will significantly reduce our support, and since this is for open source software, I would rather have more support.

For example, we use the Solaris compiler (suncc) and gcc, but there may be another compiler that we would go out of the way while we could maintain compatibility with very little effort.

For example, I never worked on Windows and knew nothing about Windows compilers, but it would be nice to maintain compatibility with Windows.

Answer 1

Some functions of the C99 are optional, so their drawback is not technically inappropriate. I will not distinguish below.

• Hmm, the win does not have <stdint.h> , although there is an open source version of stdint.h for Microsoft . Even when a 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 issues with C99 in gcc.

Answer 2

goto is still considered harmful .

---

Somehow I gathered four voices. I introduced the above expression to add frivolity, and only 30% take the concept underlying it seriously.

I expect that the overwhelming majority of the votes belong to young people who do not understand the history of programming languages. Not every goto is evil, but compared to the 100% irreplaceable spaghetti code I worked on (millions of lines of FORTRAN 66), it is reasonable and productive to replace as many goto with structured statements ( for , while , do .. while , switch ). But sometimes goto just fine when it avoids complexity, such as additional flag variables, to break out of several nested loops.

Answer 3

Well, gcc will basically be gcc, no matter what working OS you are targeting.

Visual C ++, being mainly a C ++ compiler, is not entirely interested in the C99 specification. stdint.h announces your favorite intxx_t macros. __VA_ARGS__ . _Bool, _Complex, and _Pragma are not implemented in the Microsoft Visual C ++ compiler. I am pretty sure that the fields in printf / scanf were not implemented, although perhaps VC2010 can handle them. snprintf is present, but has leading underscores and slightly different semantics.

Short answer: The “simpler” function of C99 is to implement it without changing the compiler’s grammar or replacing the standard library, all the more likely that VC ++ should support it. If there is a conflict between C99 and C ++, expect C ++ to win.

Answer 4

Runtime sizeof is a nightmare for compiler authors. Therefore, I consider it harmful.

Answer 5

glibc does not implement C99-compatible realloc , so realloc(ptr, 0) not portable.

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

Answer 6

restrict became a keyword in C99. This is an implementation that encroaches on the user namespace. If you have a valid C89 program containing the word restrict , you must modify your program to work with C99. In other words: no backward compatibility. If they were going to break backward compatibility, they should first remove gets from the standard.

Answer 7

General mathematical functions like <tgmath.h> not necessarily widely implemented, although they seem to come with GCC 4.2.1 on MacOS X 10.6.2.