# C11 (C standard revision)

C11 is the 2011 revision of the ISO standard for the C programming language, published as ISO/IEC 9899:2011 on 8 December 2011 and developed by the ISO/IEC JTC1/SC22/WG14 committee.<sup>[1](https://open-std.org/jtc1/sc22/wg14/www/standards)</sup> It succeeded C99 (ISO/IEC 9899:1999) and introduced, among other things, a memory model with atomic operations, an optional standard threading library, type-generic expressions, static assertions, and alignment control. During development the revision was referred to as C1X.<sup>[2](https://gcc.gnu.org/onlinedocs/gcc/Standards.html)</sup>

| Key fact | Detail |
|---|---|
| Standard | ISO/IEC 9899:2011, published 2011-12-08; Technical Corrigendum 1 published 2012; latest public draft is WG14 N1570, dated 2011-04-12<sup>[1](https://open-std.org/jtc1/sc22/wg14/www/standards)</sup> |
| Version macro | `__STDC_VERSION__` expands to `201112L`<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup> |
| Headline features | Atomics (`_Atomic`, `<stdatomic.h>`), threads (`<threads.h>`, optional), `_Generic`, `_Static_assert`, `_Alignas`/`_Alignof`, `_Noreturn`, `_Thread_local`, anonymous structures and unions, `<uchar.h>`<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> |
| Optional features | Variable length arrays (mandatory in C99) became optional; Annex K bounds-checking interfaces and Annex L analyzability are optional<sup>[5](https://open-std.org/jtc1/sc22/wg14/www/docs/n3437.htm)</sup><sup> • </sup><sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> |
| Removed | The `gets` function was removed from `<stdio.h>`<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> |
| Compiler support | GCC substantially complete since GCC 4.9 (`-std=c11`, `-std=gnu11`); Clang supports a significant portion (`-std=c11`); MSVC `/std:c11` since Visual Studio 2019 version 16.8<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup><sup> • </sup><sup>[6](https://clang.llvm.org/c_status.html)</sup><sup> • </sup><sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup> |
| Successor | C17 (ISO/IEC 9899:2018), a bug-fix revision of C11 with no major changes<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup> |

## What C11 added

**Concurrency.** The largest addition was a memory model for multithreaded programs. C11 defines atomic types through the `_Atomic` type qualifier and an operations interface in `<stdatomic.h>`, with memory ordering arguments such as `memory_order_relaxed`.<sup>[7](https://github.com/rmind/stdc/blob/master/c11memfences.md)</sup> Atomic types are deliberately incompatible with their plain primitive counterparts, because the standard allows implementations to realize atomics with locks on architectures that lack lock-free hardware support; code that passes an ordinary `unsigned int *` to `atomic_store_explicit` is ill-formed.<sup>[7](https://github.com/rmind/stdc/blob/master/c11memfences.md)</sup> The standard also added an optional threads library, `<threads.h>`, with thread creation, mutexes, condition variables, and thread-specific storage.<sup>[8](https://open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf)</sup> The memory model has been the subject of substantial formalization work since publication, including revised models for sequentially consistent atomics and the first rigorous memory-model formalization of OpenCL, which extends C11.<sup>[9](https://arxiv.org/abs/1503.07073)</sup>

**Language features.** C11 added `_Generic` type-generic expressions, `_Static_assert` compile-time assertions, `_Alignas` and `_Alignof` alignment control with `<stdalign.h>`, `_Noreturn` with `<stdnoreturn.h>`, the `_Thread_local` storage-class specifier, and anonymous structures and unions inside structures and unions.<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> It also incorporated the character types of the withdrawn TR 19769 into `<uchar.h>`, adding types and conversion functions for UTF-16 and UTF-32.<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> In the library, `aligned_alloc`, `at_quick_exit`, and `quick_exit` were added, and the unsafe `gets` function was removed.<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup>

**Optional features.** C11 made several large C99 features optional, most notably variable length arrays, which a conforming implementation may omit and signal with the `__STDC_NO_VLA__` macro.<sup>[5](https://open-std.org/jtc1/sc22/wg14/www/docs/n3437.htm)</sup><sup> • </sup><sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup> The motivation was to ease conformance: implementations that had stayed on C90 because of C99's large additions, such as complex arithmetic, variable length arrays, and threads, could adopt C11 without implementing all of them.<sup>[5](https://open-std.org/jtc1/sc22/wg14/www/docs/n3437.htm)</sup> Annex K, the bounds-checking interfaces such as `strcpy_s`, descended from ISO/IEC TR 24731-1:2007 and was made optional as well.<sup>[10](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm)</sup>

## Annex K in practice

The bounds-checking interfaces of Annex K aimed to mitigate a subset of buffer overflows by adding `_s`-suffixed variants of standard functions that take an explicit destination-buffer size and return an error code instead of a pointer. A 2015 WG14 field-experience paper by authors with implementation and deployment experience in a 50-million-line code base concluded that adoption requires more intrusive changes than envisioned, that testing return values and handling runtime-constraint violations had itself introduced defects, and that no viable conforming implementation had emerged nearly five years after C11's introduction; it recommended that Annex K be removed from the next revision or deprecated and then removed.<sup>[10](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm)</sup> The same paper surveyed alternatives that had become commonplace, including Address Sanitizer, GCC's Object Size Checking (`_FORTIFY_SOURCE`), and static analysis.<sup>[10](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm)</sup>

## Compiler support

**GCC** has substantially complete C11 support since GCC 4.9, selectable with `-std=c11` or, with GNU extensions, `-std=gnu11`.<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> Language features arrived across releases: `_Static_assert` and anonymous structures and unions in GCC 4.6, alignment support and `<uchar.h>` in GCC 4.7, and atomics, `_Thread_local`, and `_Generic` in GCC 4.9; library features depend on the C library, with `<threads.h>` arriving in glibc 2.28 and Annex K not implemented.<sup>[4](https://gcc.gnu.org/projects/c-status.html)</sup> GCC inlines C11 atomic operations as its own built-ins, which means code that the standard considers ill-formed, such as atomic operations on non-atomic objects, may compile without error under GCC.<sup>[7](https://github.com/rmind/stdc/blob/master/c11memfences.md)</sup>

**Clang** implements a significant portion of ISO 9899:2011, with the status of individual proposals still under investigation; C11 mode is selected with `-std=c11`, or `-std=c1x` in Clang 3.0 and earlier.<sup>[6](https://clang.llvm.org/c_status.html)</sup> Clang's default C mode was gnu17 for many releases.<sup>[11](https://clang.llvm.org/docs/UsersManual.html)</sup>

**MSVC** gained `/std:c11` in [Visual Studio](https://www.edgepedia.org/visual-studio) 2019 version 16.8, released in 2020. The option enables the required C11 features the compiler supports, including `_Generic`, `_Static_assert`, `_Alignas`, and `_Noreturn`, and automatically selects the new preprocessor. MSVC does not support most optional C11 features: it has no conforming multithreading, atomic, or complex-number support, and `aligned_alloc` is missing because of the Windows heap implementation. Feature test macros such as `__STDC_NO_VLA__` let code detect support levels.<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup>

## C11 and C17

C17 (ISO/IEC 9899:2018) is a bug-fix revision of C11 containing only technical corrections and clarifications tracked through defect reports; it adds no new features.<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup><sup> • </sup><sup>[6](https://clang.llvm.org/c_status.html)</sup> For compilers that apply the defect-report resolutions, the two modes differ only in the value of `__STDC_VERSION__`: `201112L` for C11 and `201710L` for C17.<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup> GCC applies the corrections with `-std=c11` as well, so the options differ only in the macro value.<sup>[2](https://gcc.gnu.org/onlinedocs/gcc/Standards.html)</sup>

## Adoption

Adoption of C11 has been gradual. In [JetBrains](https://www.edgepedia.org/jetbrains)' 2025 developer survey of roughly 900 C developers, 42% reported regularly using C99, 36% C11, 21% C17/C18, and 17% C23, whose share had grown from 4% at its release.<sup>[12](https://lp.jetbrains.com/the-state-of-c-2025/)</sup> In embedded development, C11 led the corresponding 2020 JetBrains survey with a 47% share, ahead of the field overall.<sup>[13](https://www.jetbrains.com/lp/devecosystem-2020/c/)</sup> A recurring practical constraint is toolchain support: embedded compilers and older platform libraries often lag the standard, which keeps C99 in wide use.<sup>[3](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)</sup>

## References

1. [ISO/IEC JTC1/SC22/WG14 - C: Approved standards](https://open-std.org/jtc1/sc22/wg14/www/standards)
2. [Standards, Using the GNU Compiler Collection (GCC)](https://gcc.gnu.org/onlinedocs/gcc/Standards.html)
3. [/std (Specify Language Standard Version), Microsoft Learn](https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version)
4. [C Standards Support in GCC, GNU Project](https://gcc.gnu.org/projects/c-status.html)
5. [N3437: Variable Length Array (VLA) Allocation Control, WG14](https://open-std.org/jtc1/sc22/wg14/www/docs/n3437.htm)
6. [Clang - C Programming Language Status](https://clang.llvm.org/c_status.html)
7. [C11 memory fences, rmind/stdc on GitHub](https://github.com/rmind/stdc/blob/master/c11memfences.md)
8. [ISO/IEC 9899:201x Committee Draft N1570, WG14](https://open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf)
9. [Overhauling SC Atomics in C11 and OpenCL, arXiv](https://arxiv.org/abs/1503.07073)
10. [N1967 - Field Experience With Annex K - Bounds Checking Interfaces, WG14](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm)
11. [Clang Compiler User's Manual](https://clang.llvm.org/docs/UsersManual.html)
12. [The State of C 2025, JetBrains](https://lp.jetbrains.com/the-state-of-c-2025/)
13. [C Programming - The State of Developer Ecosystem in 2020, JetBrains](https://www.jetbrains.com/lp/devecosystem-2020/c/)

---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Software and programming › Programming languages › Individual programming languages › C-family and imperative languages*

*Initially written Sep 17, 2026 · Reviewed: Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026*

*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*

License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license
