Chapter 10. Overview of ISO Standards Compliance

This chapter has been prepared in order to provide an overview of the compliance of the eCos Standard C and Math libraries against ISO C and C++ Standards, as implemented in eCosPro.

It is intended to describe functionality required by the ISO/IEC 9899:2011 C and ISO/IEC 14882:2011 C++ standards which is missing, as well as behaviour which differs from the standards, or only meets the specification of the standards in part. This documentation is focused on these 2011 revisions of the standards, and earlier and later revisions of these standards are not covered.

Further details on compliance with the ISO C++ standard can be found in the documentation on eCosPro's Standard C++ support.

The general approach which will be taken is to describe standards compliance with regard to the APIs defined by each standard header file, in turn. By examining compliance on a header by header basis, rather than looking at each standard in turn, it is hoped to avoid confusing duplication due to the considerable overlap in headers between the C and C++ standards.

10.1. Definitions

Some terms are frequently used in this document, or only used in shorthand form, and are defined here to allow us to reference them later more conveniently.


The ISO/IEC 9899:1990 C standard, occasionally also known as C89, or informally as “ANSI C” (which differ only in formatting with the ISO standard).


The ISO/IEC 9899:1999 C standard


The ISO/IEC 9899:2011 C standard


The ISO/IEC 14882:2011 C++ standard. Note that this standard does not implicitly require the C11 standard, but the C99 standard.


The GNU Compiler Collection, including C and C++ compilers. Unless otherwise described, this should be taken as to refer to GCC 7 including patches supplied by eCosCentric in order to support use with eCosPro. Vanilla GCC sources from the main GCC download sites are not suitable for use without the eCosPro-specific patches.


The Standard C++ Library provided by GCC. It provides much of the library functionality defined by the C++ standard.

10.2. Scope

Broadly, this documentation is only intended as an overview. Although it is intended to cover as much as possible, it is not guaranteed to be fully complete. While broad areas of non-compliance should be identified here, some elements of finer detail not in compliance with the standards may not have been addressed. As a result, this documentation does not warrant that, just because non-compliance has not been identified here, that that means that eCosPro and GCC are fully compliant in all remaining areas.

At time of writing, eCosPro is currently supplied with GCC 7, which is a version of the compiler intended to be compliant with the C11 and C++11 standards.

Although there are exceptions, in general, GCC provides language parts of standard, eCos provides runtime library parts of standard, but GCC must interact with eCos for various abstractions. GCC also provides the Standard C++ Library (libstdc++). In this document, we do not cover conformance of portions provided by GCC, including the majority of the very large Standard C++ library.

For more information on GCC’s standards compliance, the webpage at may be informative (also note that the similarly named webpage refers to GCC standards compliance information for the very latest version of GCC, and not necessarily the version supplied by eCosCentric for use with eCosPro).

There is also detailed information on GCC’s ongoing compliance efforts with the various C++ standards, described at

This documentation only covers compliance against the C11 and C++11 standards. It does not cover the specifics of more recent revisions of the standards such as C18, C++14 or C++17, even though it is understood some of the differences are well understood, and for example in the case of C++11 versus C++14, the differences are relatively small.

10.3. General Overview

Much of the support for the runtime library portions of the standards comes from the C library suite of packages, with certain elements also coming from the Infrastructure package. In general, the eCos C library was written to be compliant with the C90 standard, with some elements of C99 compliance added subsequently.

Particularly notable and wide-ranging omissions are in the areas of internationalization and localization, such as wide character and multibyte character variations of functions, many of which are absent. This also affects the level of internationalization/localization functionality that libstdc++ is able to provide as well.

Standard eCos headers occasionally make use of identifiers which are not reserved by the standard, which means that these identifiers may not be able to be used by programs which would otherwise be C11/C++11 standards-compliant. This is typically known as “namespace pollution”, and fortunately is usually easy to work around.

Building with the GCC compiler flag -std=… may not work as intended as eCos headers do not always adapt to different language standard requirements.

Function prototypes that are expected to use the “restrict” keyword for arguments widely do not do so.

Annex K of C11 describes bounds-checking variants of many standard functions. This is an optional part of the standard and eCos does not implement it.

Feature-test macros such as those defined in C11 sections and (all of which begin with the prefix “__STDC_”) are not defined.

10.4. Common C/C++ headers

These headers are required by both the C11 and C++11 standards, although note that strictly C++11 itself only requires C99 compliance.

In all cases, where the C++11 standard describes a C++ wrapper for the listed header files, such as <cassert> for <assert.h> or <cstdlib> for <stdlib.h>, these comments apply equally to headers included via these wrappers.

10.4.1. <assert.h>

static_assert is not defined.

10.4.2. <complex.h>

This header is not provided if compiling for C11. Unusually, a compatibility header is provided by GCC if compiling for C++11 to provide an implementation of specific elements from the C++ standard.

10.4.3. <ctype.h>

No compliance issues noticed.

10.4.4. <errno.h>

No compliance issues noticed.

10.4.5. <fenv.h>

This header is not supported by eCos.

10.4.6. <float.h>

No compliance issues noticed.

10.4.7. <inttypes.h>

This header is provided by eCos. It includes integer type format string definitions to be used with the printf() and scanf() families of functions. It also includes the imaxabs(), imaxdiv(), strtoimax() and strtoumax() functions. However the wide character related functions wcstoimax() and wcstoumax() are not implemented.

10.4.8. <iso646.h>

No compliance issues noticed.

10.4.9. <limits.h>

No compliance issues noticed.

10.4.10. <locale.h>

struct lconv” does not contain members: int_p_cs_precedes, int_n_cs_precedes, int_p_sep_by_space, int_n_sep_by_space, int_p_sign_posn, int_n_sign_posn.

10.4.11. <math.h>

The following identifiers are not defined: HUGE_VALL, INFINITY, NAN, FP_FASTFMA*, FP_ILOG*.

Error handling does not use math_errhandling to generate floating point exceptions. MATH_ERRNO, MATH_ERREXCEPT, math_errhandling are not defined.

No “long double” variants of any maths functions are provided. For example, sin() and sinf() are provided, but not sinl().

None of llround(), llroundf() or llroundl() are provided. None of the nexttoward(), nexttowardf(), nexttowardl() functions are provided.

10.4.12. <setjmp.h>

While in general the <setjmp.h> functionality operates as defined, it is worth noting that in line with the comments about <signal.h>, in eCos configurations where the POSIX package is not used and where a hardware exception context is used to handle hardware exception related signals (SIGSEGV, SIGILL, etc.) the fact that the signal handler is being called in a non-standard CPU context means that the practice of longjmp()ing out of a signal handler must be avoided.

10.4.13. <signal.h>

The signal subsystem is broadly compliant. But it is worth noting that if the eCos configuration is set to use the C library signals package (CYGPKG_LIBC_SIGNALS), then while signals generated (with raise()) by software behave normally, hardware-related signals such as SIGILL, SIGFPE or SIGSEGV may result in the signal handler being invoked in an unusual CPU context such as an exception context, and the effect of returning from the signal handler or attempting to longjmp() out of it is undefined. In an exception context, calling certain functions such as those which may interact with synchronisation objects (mutexes etc.) or cause pre-emption are likely to misbehave.

For compliant behaviour, instead it is recommended to use the signals facility provide by the eCos POSIX compatibility package (CYGPKG_POSIX) in place of CYGPKG_LIBC_SIGNALS.

10.4.14. <stdarg.h>

No compliance issues noticed.

10.4.15. <stdbool.h>

No compliance issues noticed.

10.4.16. <stddef.h>

No compliance issues noticed.

10.4.17. <stdint.h>

No compliance issues noticed.

10.4.18. <stdio.h>

None of the wide character input or output functions, nor any other definitions and functionality related to wide character support, are provided. These include at least the functions: fgetwc(), fgetws(), getwc(), getwchar(), fwscanf(), wscanf(), vfwscanf(), vwscanf(), fputwc(), fputws(), putwc(), putwchar(), fwprintf(), wprintf(), vfwprintf(), vwprintf() and ungetwc(). It also includes the mbstate_t type.

freopen() will always report an error on return.

Not all format specifiers or length modifiers for the *printf() and *scanf() families of functions are supported. For example: the ‘a’ and ‘A’ floating-point format specifiers, the ‘j’ length modifier for intmax_t / uintmax_t, or the ‘t’ length modifier for ptrdiff_t. Also the ‘l’ length modifier where its behaviour is intended to treat the associated characters/string as wide characters.

10.4.19. <stdlib.h>

The llabs() and lldiv() functions, and associated lldiv_t type are not provided.

The strtold() function is not supported.

The strtod() and strtof() functions (and implicitly atof()) do not accept input text of the form: a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a decimal-point character, then an optional binary exponent part. They also do not recognise the special strings INF, INFINITY, or any NAN strings.

The aligned_alloc() function is not provided.

The _Exit(), quick_exit() and at_quick_exit() functions are not provided.

As eCos is designed for embedded systems, it is not intended for its main process to exit, as there is no other process to return to. Therefore while functions like abort(), exit(), and atexit() exist and are implemented, for that reason they may not behave in the expected way that developers using Unix systems may expect. Depending on eCos configuration, exiting may cause the system to halt, or only cause the main() thread to exit, allowing other threads to continue running.

10.4.20. <string.h>

No compliance issues noticed.

10.4.21. <tgmath.h>

This header file is not supported.

10.4.22. <time.h>

Some conversion specifiers for strftime() are not supported, for example: %C, %F, %g, %G, %h, %n, %r, %R, %t, %u, %V, %z. Also, the ‘E’ and ‘O’ modifiers are not supported.

10.4.23. <wchar.h>

This header file is not supported.

10.4.24. <wctype.h>

This header file is not supported.

10.5. C11 specific headers

10.5.1. <stdalign.h>

No compliance issues noticed.

10.5.2. <stdatomic.h>

Although eCosCentric has not tested this functionality, no compliance issues have been noticed.

10.5.3. <threads.h>

This header file is not supported.

10.5.4. <uchar.h>

This header file is not supported.