GCC 8 selects GNU C17 by default

The C revision selected by a plain GCC command has changed, even though the new revision does not introduce a corresponding collection of language features. GCC 8.1 was released on May 2, and its default C dialect is GNU C17. The 8.1 dialect documentation identifies gnu17 as that default and describes C17 as C11 with defect corrections and a new __STDC_VERSION__ value.

The same documentation says that GCC applies the defect corrections in C11 mode as well. Selecting C17 consequently does not switch those repairs on for the first time. The meaningful differences are the selected revision's identity and the preprocessor information that exposes it. GNU mode is a further choice about extensions, independent of whether the underlying corrected revision is called C11 or C17.

I value C partly because its language is small enough to understand in detail. A correction release fits that preference, but the compiler's default deserves a precise description. Calling the change a new C17 feature set would misrepresent what an application gains merely by changing its language option.

The implementation selects the dialect before processing options

The GCC 8.1 C-family option implementation makes the default explicit. When the selected language is C, initialization calls set_std_c17 with its ISO argument false. Later option handling distinguishes -std=c17, which passes true, from -std=gnu17, which passes false.

This is useful evidence because it separates the compiler's initial selection from any flag a build later supplies. A project that names an older dialect is making an explicit choice. A project that omits a dialect accepts the compiler's initialized default. Changing the installed GCC version can therefore change the latter build's declared language revision without any edit to its command line.

The difference can be expressed with two commands that make the selection visible:

gcc -std=c17 -Wpedantic -c parser.c
gcc -std=gnu17 -Wpedantic -c parser.c

Both commands request the corrected revision. Their extension policies differ. The dialect manual explains that a base-standard option disables GNU extensions where they conflict with that standard. A GNU dialect enables supported extensions even where they change the base standard's meaning. -Wpedantic uses the selected base standard to identify extensions that deserve a diagnostic.

An ISO dialect option alone does not promise that GCC will reject every extension. The manual explicitly distinguishes selecting the base language from requesting its diagnostics. That distinction explains why a build can accept source under -std=c17 that still depends on a GNU facility. The acceptance of one compilation unit does not establish that the source is portable to every implementation of the selected standard.

The version macro identifies the requested revision

The 8.1 standards chapter states that C11 and C17 modes apply the same corrections. Their difference is the value of __STDC_VERSION__. Code that tests that macro can therefore choose a different preprocessing branch after the default changes, even when the compiler's treatment of the relevant corrected construct is unchanged.

That is a narrow but practical consequence. A configure check that asks which revision is selected differs from a check that asks whether a particular construct works. The first can change with the default macro. The second depends on the implementation's support for the tested operation. A correction already applied to C11 does not become unavailable simply because the macro still names C11.

There is a documentation inconsistency worth recognizing. The standards chapter still says that the default C dialect is gnu11, while the dialect-options chapter says gnu17. The release implementation resolves the question by selecting C17 during initialization. Treating all sentences in the manual as equally current would leave the reader with two incompatible answers.

The spelling aliases add another possible source of confusion. The dialect chapter accepts c17 and c18, together with the corresponding ISO-number spellings. It describes the revision as expected to be published in 2018. These names do not identify separate sets of new language facilities. They refer to the correction revision as understood by this release's compiler.

Choosing a language mode does not supply a C library

The standards chapter distinguishes the compiler from the library facilities needed by a hosted implementation. GCC does not itself provide those hosted facilities. A system using GCC needs a suitable library, such as the GNU C Library, to supply them. Changing the language option therefore cannot by itself establish the availability of every library interface associated with that language revision.

The same chapter distinguishes hosted and freestanding environments. GCC normally assumes a hosted environment. -ffreestanding changes that assumption and sets __STDC_HOSTED__ to zero. Startup and linking still require the arrangements appropriate to the target environment, which may not enter application code through the ordinary hosted main interface.

These distinctions prevent an overly broad interpretation of the new default. The dialect names the source-language rules GCC should apply. Hosting describes assumptions about the execution environment. Library availability depends on the accompanying implementation. A build can select the corrected C language while still needing a separate answer about which runtime facilities it can call.

C's importance at foreign-function and platform boundaries makes that separation particularly useful to me. A compiler mode is one part of an interface contract. The library and target conventions remain part of the contract even when the source language changes very little.

New diagnostics are independent evidence about the source

The release announcement also calls attention to improved diagnostics and new warnings. Those changes should not be attributed to C17 itself. GCC can improve its account of an existing program while implementing the same base-language rule. A newly reported problem does not necessarily indicate a newly prohibited construct.

The GCC 8 changes document describes -Wstringop-truncation, included in -Wall. It diagnoses bounded string operations that may truncate output or fail to produce the intended string. One example copies into a buffer using its full size as the strncpy bound. When the source fills that bound, the result lacks a terminating null character.

That example exposes a distinction between a bounded copy and a terminated string. Limiting the number of copied characters does not automatically satisfy the receiving code's representation requirement. The diagnostic is about how the call's bound relates to that requirement. It is not evidence that C17 changed strncpy into a different function.

Another warning, -Wsizeof-pointer-div, addresses a division that resembles array-length computation but applies sizeof to a pointer. The numerator then describes the pointer object, not the number of elements in an array. The expression's familiar appearance can conceal that difference. GCC 8 adds a warning for the suspicious form under -Wall.

The release also expands -Wrestrict for overlapping accesses through restricted arguments to memory and string functions. Its strcpy example copies a suffix over the beginning of the same array. The terminating null character makes the ranges overlap even where the visible non-null characters might suggest otherwise. The warning therefore depends on the complete operation, including termination.

A default can change the build's description without changing its intent

The useful practical distinction is between an omitted language choice and an explicit one. Under GCC 8.1, omission selects GNU C17. Naming c17 selects the base revision's mode, while naming gnu17 preserves the GNU dialect choice explicitly. Neither spelling substitutes for understanding which extensions the source actually uses.

The shared corrections also give C11 builds a clear interpretation. Retaining -std=c11 does not request GCC's old, uncorrected handling of every defect. The manual says those corrections apply there too. A project can retain that revision name for compatibility reasons without treating all compiler improvements as changes to its selected standard.

There is also a difference between a warning policy and an extension policy. The dialect manual notes that -Wpedantic identifies extensions relative to the chosen base standard even in a GNU mode. A build can therefore use GNU C17 deliberately while asking GCC to report departures from the base language. Whether the build accepts those diagnostics is a further decision, separate from the standard revision named by the compiler.

For this release, the new default is best understood through those specific mechanisms. Initialization selects GNU C17, the version macro identifies that selection, and the diagnostic machinery can report additional information about existing code. The corresponding library and execution environment continue to determine which runtime facilities the resulting program can use.