#4 should only bite you if you have a bad coding style, or use poorly designed libraries.
#5 will be caught by any decent compiler.
#6 is a bit nasty - endianness is a bother. I believe the standard (or some other "authorative" text), anyway, says something to the effect of "bitfields should only be used for in-memory representations".
#7 is poor coding style and trying to be "cute" rather than clear.
#9 macros are bad
- but yeah, C is very permissive.
#10 will be caught by any decent compiler.
#11 looks a bit nasty... but so does the code.
#13 C++ rectifies this somewhat with namespaces. Too bad there's so much legacy code, and too bad #define macros are used for these things (the preprocessor knows nothing about scope, let alone namespaces).
#14 that's the price you pay for trying to use optimal machine-native int size. Go by what the standard says about integer types, and define your own typedefs for when you need specific sizes.
#15 speed over safety... you can always make up your own bounds-checked stuff if you need it. Or move to C++ STL containers.
#16 octal numbers in C suck. They should have made "0o" like there's "0x". Of course in some fonts that will look utterly stupid, but then again, so are those fonts
#17 I agree on that too. IMHO chars should have been unsigned, or perhaps there should have been no "neutral-sounding" types, requiring "sint/uint", "schar/uchar", etc...