how to C

How to C in 2016

This is a draft I wrote in early 2015 and never got around to publishing. Here's the mostly unpolished version because it wasn't doing anybody any good sitting in my drafts folder. The simplest change was updating year 2015 to 2016 at publication time.

Feel free to submit fixes/improvements/complaints as necessary. -Matt

Adrián Arroyo Calle provides a Spanish translation at ¿Cómo programar en C (en 2016)?

Japanese POSTD provides a Japanese translation at 2016年、C言語はどう書くべきか (前編) and 2016年、C言語はどう書くべきか (後編).

Chinese InfoQ provides a Chinese translation at C语言的2016.

Programmer Magazine provides a Chinese translation at 2016年，C语言该怎样写 (as PDF too).

Keith Thompson provides a nice set of corrections and alternative opinions at howto-c-response.

Rob Graham provides a response covering other avenues out of scope here at Some notes C in 2016.

Now on to the article...

The first rule of C is don't write C if you can avoid it.

If you must write in C, you should follow modern rules.

C has been around since the early 1970s. People have "learned C" at various points during its evolution, but knowledge usually get stuck after learning, so everybody has a different set of things they believe about C based on the year(s) they first started learning.

It's important to not remain stuck in your "things I learned in the 80s/90s" mindset of C development.

This page assumes you are on a modern platform conforming to modern standards and you have no excessive legacy compatibility requirements. We shouldn't be globally tied to ancient standards just because some companies refuse to upgrade 20 year old systems.

Preflight

Standard c99 (c99 means "C Standard from 1999"; c11 means "C Standard from 2011", so 11 > 99).

• clang, default
  • clang uses an extended version of C11 by default (GNU C11 mode), so no extra options are needed for modern features.
  • If you want standard C11, you need to specify -std=c11; if you want standard C99, use -std=c99.
  • clang compiles your source files faster than gcc
• gcc requires you specify -std=c99 or -std=c11
  • gcc builds source files slower than clang, but sometimes generates faster code. Performance comparisons and regression testings are important.
  • gcc-5 defaults to GNU C11 mode (same as clang), but if you need exactly c11 or c99, you should still specify -std=c11 or -std=c99.

Optimizations

• -O2, -O3
  • generally you want -O2, but sometimes you want -O3. Test under both levels (and across compilers) then keep the best performing binaries.
• -Os
  • -Os helps if your concern is cache efficiency (which it should be)

Warnings

• -Wall -Wextra -pedantic
  • newer compiler versions have -Wpedantic, but they still accept the ancient -pedantic as well for wider backwards compatibility.
• during testing you should add -Werror and -Wshadow on all your platforms
  • it can be tricky deploying production source using -Werror because different platforms and compilers and libraries can emit different warnings. You probably don't want to kill a user's entire build just because their version of GCC on a platform you've never seen complains in new and wonderous ways.
• extra fancy options include -Wstrict-overflow -fno-strict-aliasing
  • Either specify -fno-strict-aliasing or be sure to only access objects as the type they have at creation. Since so much existing C code aliases across types, using -fno-strict-aliasing is a much safer bet if you don't control the entire underlying source tree.
• as of now, Clang reports some valid syntax as a warning, so you should add -Wno-missing-field-initializers
  • GCC fixed this unnecessary warning after GCC 4.7.0

Building

• Compilation units
  • The most common way of building C projects is to decompose every source file into an object file then link all the objects together at the end. This procedure works great for incremental development, but it is suboptimal for performance and optimization. Your compiler can't detect potential optimizations across file boundaries this way.
    
• LTO — Link Time Optimization
  • LTO fixes the "source analysis and optimization across compilation units problem" by annotating object files with intermediate representation so source-aware optimizations can be carried out across compilation units at link time.
  • LTO can slow down the linking process noticeably, but make -j helps if your build includes multiple non-interdependent final targets (.a, .so, .dylib, testing executables, application executables, etc).
  • clang LTO (guide)
  • gcc LTO
  • As of 2016, clang and gcc releases support LTO by just adding -flto to your command line options during object compilation and final library/program linking.
  • LTO still needs some babysitting though. Sometimes, if your program has code not used directly but used by additional libraries, LTO can evict functions or code because it detects, globally when linking, some code is unused/unreachable and doesn't need to be included in the final linked result.

Arch

• -march=native
  • give the compiler permission to use your CPU's full feature set
  • again, performance testing and regression testing is important (then comparing the results across multiple compilers and/or compiler versions) is important to make sure any enabled optimizations don't have adverse side effects.
• -msse2 and -msse4.2 may be useful if you need to target not-your-build-machine features.

Writing code

Types

If you find yourself typing char or int or short or long or unsigned into new code, you're doing it wrong.

For modern programs, you should #include <stdint.h> then use standard types.

For more details, see the stdint.h specification.

The common standard types are:

• int8_t, int16_t, int32_t, int64_t — signed integers
• uint8_t, uint16_t, uint32_t, uint64_t — unsigned integers
• float — standard 32-bit floating point
• double - standard 64-bit floating point

Notice we don't have char anymore. char is actually misnamed and misused in C.

Developers routinely abuse char to mean "byte" even when they are doing unsigned byte manipulations. It's much cleaner to use uint8_t to mean single a unsigned-byte/octet-value and uint8_t * to mean sequence-of-unsigned-byte/octet-values.

Special Standard Types

In addition to standard fixed-width like uint16_t and int32_t, we also have fast and least types defined in the stdint.h specification.

Fast types are:

• int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t — signed integers
• uint_fast8_t, uint_fast16_t, uint_fast32_t, uint_fast64_t — unsigned integers

Fast types provide a minimum of X bits, but there is no guarantee the underlying storage size is exactly what you request. If a larger type has better support on your target platform, a fast type will automatically use the better supported larger type.

The best example here is, on some 64-bit systems, when you request uint_fast16_t you actually get a uint64_t because operating on word-sized integers will be faster than operating on half of a 32-bit integer.

The fast guidelines aren't followed on every system though. One standout is OS X, where fast types are defined exactly as their corresponding fixed width counterparts.

Fast types can be useful for self-documenting code as well. If you know your counters only need 16 bits, but you prefer your math use 64 bit integers because they are faster on your platform, that's where uint_fast16_t would help. Under 64-bit Linux platforms, uint_fast16_t gives you a fast 64-bit counter while maintaining the code-level inline documentation of "we only need 16 bits here."

One thing to be aware of for fast types: it can impact certain test cases. If you need to test for storage width edge cases, having uint_fast16_t be 16 bits on some platforms (OS X) and 64 bits on other platforms (Linux) can increase the minimum number of platforms where your tests need to pass.

Fast types do introduce the same uncertainty as int not being a standard size across platforms, but with fast types, you can limit your uncertainty to known-safe locations in your code (counters, temporary values with checked bounds, etc).

Least types are:

• int_least8_t, int_least16_t, int_least32_t, int_least64_t — signed integers
• uint_least8_t, uint_least16_t, uint_least32_t, uint_least64_t — unsigned integers

Least types provide you with the most compact number of bits for the type you request.

The least guidelines, in practice, mean least types are just defined to standard fixed width types, since standard fixed width types already provide the exact minimum number of bits you request.

to int or not to int

Some readers have pointed out they truly love int and you'll have to pry it from their cold dead fingers. I'd like to point out is is technically impossible to program correctly if the sizes of your types change out from under you.

Also see RATIONALE included with inttypes.h for reasons why using non-fixed-width types is unsafe. If you are truly smart enough to conceptualize int being 16 bits on some platforms and 32 bits on other platforms throughout your development while also testing all 16 bit and 32 bit edge cases for every place you use int, please feel free to use int.

For the rest of us who can't hold entire multi-level decision tree platform specification hierarchies in our heads while writing fizzbuzz, we can use fixed width types and automatically have more correct code with much less conceptual hassle and much less required testing overhead.

Or, said more concisely in the specification: "the ISO C standard integer promotion rule can produce silent changes unexpectedly."

Good luck with that.

One Exception to never-char

The only acceptable use of char in 2016 is if a pre-existing API requires char (e.g. strncat, printf'ing "%s", ...) or if you're initializing a read-only string (e.g. const char *hello = "hello";) because the C type of string literals ("hello") is char [].

ALSO: In C11 we have native unicode support, and the type of UTF-8 string literals is still char [] even for multibyte sequences like const char *abcgrr = u8"abc