| Chapter 10. Overview of ISO Standards Compliance | ||
|---|---|---|
 | Part III. The ISO Standard C and Math Libraries |  |
Chapter 10. Overview of ISO Standards Compliance
Table of Contents
- 10.1. Definitions
- 10.2. Scope
- 10.3. General Overview
- 10.4. Common C/C++ headers
- 10.4.1.
<assert.h> - 10.4.2.
<complex.h> - 10.4.3.
<ctype.h> - 10.4.4.
<errno.h> - 10.4.5.
<fenv.h> - 10.4.6.
<float.h> - 10.4.7.
<inttypes.h> - 10.4.8.
<iso646.h> - 10.4.9.
<limits.h> - 10.4.10.
<locale.h> - 10.4.11.
<math.h> - 10.4.12.
<setjmp.h> - 10.4.13.
<signal.h> - 10.4.14.
<stdarg.h> - 10.4.15.
<stdbool.h> - 10.4.16.
<stddef.h> - 10.4.17.
<stdint.h> - 10.4.18.
<stdio.h> - 10.4.19.
<stdlib.h> - 10.4.20.
<string.h> - 10.4.21.
<tgmath.h> - 10.4.22.
<time.h> - 10.4.23.
<wchar.h> - 10.4.24.
<wctype.h>
- 10.4.1.
- 10.5. C11 specific headers
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.
- C90
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).
- C99
The ISO/IEC 9899:1999 C standard
- C11
The ISO/IEC 9899:2011 C standard
- C++11
The ISO/IEC 14882:2011 C++ standard. Note that this standard does not implicitly require the C11 standard, but the C99 standard.
- GCC
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.
- libstdc++
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 https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Standards.html may be informative (also note that the similarly named webpage https://gcc.gnu.org/onlinedocs/gcc/Standards.html 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 https://www.gnu.org/software/gcc/projects/cxx-status.html.
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 6.10.8.2 and
6.10.8.3 (all of which begin with the prefix
“__STDC_”) are not defined.
10.4. Common C/C++ headers
- 10.4.1.
<assert.h> - 10.4.2.
<complex.h> - 10.4.3.
<ctype.h> - 10.4.4.
<errno.h> - 10.4.5.
<fenv.h> - 10.4.6.
<float.h> - 10.4.7.
<inttypes.h> - 10.4.8.
<iso646.h> - 10.4.9.
<limits.h> - 10.4.10.
<locale.h> - 10.4.11.
<math.h> - 10.4.12.
<setjmp.h> - 10.4.13.
<signal.h> - 10.4.14.
<stdarg.h> - 10.4.15.
<stdbool.h> - 10.4.16.
<stddef.h> - 10.4.17.
<stdint.h> - 10.4.18.
<stdio.h> - 10.4.19.
<stdlib.h> - 10.4.20.
<string.h> - 10.4.21.
<tgmath.h> - 10.4.22.
<time.h> - 10.4.23.
<wchar.h> - 10.4.24.
<wctype.h>
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.
| |  | |
| Chapter 9. C and math library overview |  | Part IV. eCosPro Standard C++ library support package |
| 2024-03-18 | Open Publication License |