[T106][ZXW-22]7520V3SCV2.01.01.02P42U09_VEC_V0.8_AP_VEC origin source commit
Change-Id: Ic6e05d89ecd62fc34f82b23dcf306c93764aec4b
diff --git a/ap/libc/glibc/glibc-2.22/CONFORMANCE b/ap/libc/glibc/glibc-2.22/CONFORMANCE
new file mode 100644
index 0000000..b23318e
--- /dev/null
+++ b/ap/libc/glibc/glibc-2.22/CONFORMANCE
@@ -0,0 +1,168 @@
+Conformance of the GNU libc with various standards
+==================================================
+
+The GNU libc is designed to be conformant with existing standard as
+far as possible. To ensure this I've run various tests. The results
+are presented here.
+
+
+Open Group's hdrchk
+===================
+
+The hdrchk test suite is available from the Open Group at
+
+ ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/
+
+I've last run the suite on 2004-04-17 on a Linux/x86 system running
+a Fedora Core 2 test 2 + updates with the following results [*]:
+
+ FIPS No reported problems
+
+ POSIX90 No reported problems
+
+ XPG3 Prototypes are now in the correct header file
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*** Starting unistd.h
+Missing: extern char * cuserid();
+Missing: extern int rename();
+*** Completed unistd.h
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ XPG4 Prototype is now in the correct header file
+ and the _POSIX2_C_VERSION symbol has been removed
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*** Starting unistd.h
+Missing: extern char * cuserid();
+Missing: #define _POSIX2_C_VERSION (-1L)
+*** Completed unistd.h
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ POSIX96 Prototype moved
+ (using "base realtime threads" subsets)
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*** Starting unistd.h
+Missing: extern int pthread_atfork();
+*** Completed unistd.h
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ UNIX98 Prototypes moved and _POSIX2_C_VERSION removed
+ (using "base realtime threads mse lfs" subset)
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*** Starting unistd.h
+Missing: extern char * cuserid();
+Missing: #define _POSIX2_C_VERSION (-1L)
+Missing: extern int pthread_atfork();
+*** Completed unistd.h
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+That means all the reported issues are due to the headers having been
+cleaned up for recent POSIX/Unix specification versions. Duplicated
+prototypes have been removed and obsolete symbols have been removed.
+Which means that as far as the tests performed by the script go, the
+headers files comply to the current POSIX/Unix specification.
+
+
+[*] Since the scripts are not clever enough for the way gcc handles
+include files (namely, putting some of them in gcc-local directory) I
+copied over the iso646.h, float.h, and stddef.h headers and ignored the
+problems resulting from the split limits.h file).
+
+
+Technical C standards conformance issues in glibc
+=================================================
+
+If you compile programs against glibc with __STRICT_ANSI__ defined
+(as, for example, by gcc -ansi, gcc -std=c89, gcc -std=iso1990:199409
+or gcc -std=c99), and use only the headers specified by the version of
+the C standard chosen, glibc will attempt to conform to that version
+of the C standard (as indicated by __STDC_VERSION__):
+
+GCC options Standard version
+-ansi ISO/IEC 9899:1990
+-std=c89 ISO/IEC 9899:1990
+-std=iso9899:199409 ISO/IEC 9899:1990 as amended by Amd.1:1995
+-std=c99 ISO/IEC 9899:1999
+
+(Note that -std=c99 is not available in GCC 2.95.2, and that no
+version of GCC presently existing implements the full C99 standard.)
+
+You may then define additional feature test macros to enable the
+features from other standards, and use the headers defined in those
+standards (for example, defining _POSIX_C_SOURCE to be 199506L to
+enable features from ISO/IEC 9945-1:1996).
+
+There are some technical ways in which glibc is known not to conform
+to the supported versions of the C standard, as detailed below. Some
+of these relate to defects in the standard that are expected to be
+fixed, or to compiler limitations.
+
+
+Defects in the C99 standard
+===========================
+
+Some defects in C99 were corrected in Technical Corrigendum 1 to that
+standard. glibc follows the corrected specification.
+
+
+Implementation of library functions
+===================================
+
+The implementation of some library functions does not fully follow the
+standard specification:
+
+C99 added additional forms of floating point constants (hexadecimal
+constants, NaNs and infinities) to be recognised by strtod() and
+scanf(). The effect is to change the behavior of some strictly
+conforming C90 programs; glibc implements the C99 versions only
+irrespective of the standard version selected.
+
+C99 added %a as another scanf format specifier for floating point
+values. This conflicts with the glibc extension where %as, %a[ and
+%aS mean to allocate the string for the data read. A strictly
+conforming C99 program using %as, %a[ or %aS in a scanf format string
+will misbehave under glibc if it does not include <stdio.h> and
+instead declares scanf itself; if it gets the declaration of scanf
+from <stdio.h>, it will use a C99-conforming version.
+
+
+Compiler limitations
+====================
+
+The macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and
+__STDC_ISO_10646__ are properly supposed to be constant throughout the
+translation unit (before and after any library headers are included).
+However, they mainly relate to library features, and GCC only knows to
+preinclude <stdc-predef.h> to get their definitions in version 4.8 and
+later. Programs that test them before including any standard headers
+may misbehave with older compilers.
+
+GCC doesn't support the optional imaginary types. Nor does it
+understand the keyword _Complex before GCC 3.0. This has the
+corresponding impact on the relevant headers.
+
+glibc's <tgmath.h> implementation is arcane but thought to work
+correctly; a clean and comprehensible version requires compiler
+builtins.
+
+For most of the headers required of freestanding implementations,
+glibc relies on GCC to provide correct versions. (At present, glibc
+provides <stdint.h>, and GCC doesn't before version 4.5.)
+
+The definition of math_errhandling conforms so long as no translation
+unit using math_errhandling is compiled with -fno-math-errno,
+-fno-trapping-math or options such as -ffast-math that imply these
+options. math_errhandling is only conditionally defined depending on
+__FAST_MATH__; the compiler does not provide the information needed
+for more exact definitions based on settings of -fno-math-errno and
+-fno-trapping-math, possibly for only some source files in a program.
+
+
+Issues with headers
+===================
+
+None known.