Linked by Thom Holwerda on Wed 22nd Feb 2012 15:24 UTC, submitted by Ajeet
Thread beginning with comment 508248
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
There are many language features like how overflow behaves, numeric type size, and a few other things that are not specified in the C standard. It is quite funny to see how even "expert" C developers fall in those traps.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.ht...
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14...
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21...




Member since:
2005-07-07
*snip*
As far as i know microsoft's C compiler doe not support C99.
*snip*
None of the commonly used compilers are C99 compliant. See http://en.wikipedia.org/wiki/C99. GCC which is widely used has only implemented 43 features, 6 are missing, 1 is broken and 12 suffer from "library issues". 12 years after the C99 standard is ratified, the fact that the majority of compilers do not support the standard shows how irrelevant that standard is to the real world. In fact, given the broken support of C99 among the popular compilers (i.e. GCC, Visual C++, Intel C++, Clang) you'd have to be stupid to use C99 features if portability is your goal.
Having said that, the biggest hurdles to portability have little to do with language standard compliance unless that code is written by some diva developer who wants to show how uber-1337 they are. Having ported code to across operating systems and architectures, the biggest issues to be aware off were bitness and endianess issues, and subtle difference in API routines. One that bit me before is how the POSIX function fsync() has different semantics on different supposedly "POSIX compliant" platforms. http://rhaas.blogspot.com/2010/10/wal-reliability.html
Standards are only valuable if they're adhered to.