http://www.concise-courses.

com/security/top-ten-distros/ User: bugtraq Pass: 123456 C standard library From Wikipedia, the free encyclopedia (Redirected from C Standard Library) Jump to: navigation, search C Standard Library Data types Character classification Strings Mathematics File input/output Date/time Localization Memory allocation Process control Signals Alternative tokens Miscellaneous headers: <assert.h> <errno.h> <setjmp.h> <stdarg.h> v t e The C Standard Library is the standard library for the C programming language, a s specified in the ANSI C standard.[1] It was developed at the same time as the C POSIX library, which is a superset of it[citation needed]. Since ANSI C was ad opted by the International Organization for Standardization,[2] the C standard l ibrary is also called the ISO C library. The C standard library provides macros, type definitions, and functions for task s like string handling, mathematical computations, input/output processing, memo ry allocation and several other operating system services. Contents 1 Application programming interface 1.1 Header files 1.2 Documentation 2 Implementations 2.1 Compiler built-in functions 2.2 Linking, libm 2.3 Detection 3 Concepts, problems, workarounds 3.1 Buffer overflow vulnerabilities 3.2 Threading problems, vulnerability to race conditions 3.3 Error handling 4 Standardization 4.1 POSIX standard library 4.2 Ongoing work 5 The C standard library in other languages

6 Comparison to standard libraries of other languages 7 See also 8 References 9 Further reading 10 External links Application programming interface Header files The application programming interface (API) of the C standard library is declare d in a number of header files. Each header file contains one or more function de clarations, data type definitions, and macros. After a long period of stability, three new header files (iso646.h, wchar.h, and wctype.h) were added with Normative Addendum 1 (NA1), an addition to the C Stan dard ratified in 1995. Six more header files (complex.h, fenv.h, inttypes.h, std bool.h, stdint.h, and tgmath.h) were added with C99, a revision to the C Standar d published in 1999, and five more files (stdalign.h, stdatomic.h, stdnoreturn.h , threads.h, and uchar.h) with C11 in 2011. In total, there are now 29 header fi les: Name From Description <assert.h> Contains the assert macro, used to assist with detecting logical errors and other types of bug in debugging versions of a program. <complex.h> C99 A set of functions for manipulating complex numbers. <ctype.h> Defines set of functions used to classify characters by their types or to convert between upper and lower case in a way that is independ ent of the used character set (typically ASCII or one of its extensions, althoug h implementations utilizing EBCDIC are also known). <errno.h> For testing error codes reported by library functions. <fenv.h> C99 Defines a set of functions for controlling floating-poin t environment. <float.h> Defines macro constants specifying the implementation-sp ecific properties of the floating-point library. <inttypes.h> C99 Defines exact width integer types. <iso646.h> NA1 Defines several macros that implement alternative ways t o express several standard tokens. For programming in ISO 646 variant character sets. <limits.h> Defines macro constants specifying the implementation-sp ecific properties of the integer types. <locale.h> Defines localization functions. <math.h> Defines common mathematical functions. <setjmp.h> Declares the macros setjmp and longjmp, which are used f or non-local exits. <signal.h> Defines signal handling functions. <stdalign.h> C11 For querying and specifying the alignment of objects. <stdarg.h> For accessing a varying number of arguments passed to fu nctions. <stdatomic.h> C11 For atomic operations on data shared between threads. <stdbool.h> C99 Defines a boolean data type. <stddef.h> Defines several useful types and macros. <stdint.h> C99 Defines exact width integer types. <stdio.h> Defines core input and output functions <stdlib.h> Defines numeric conversion functions, pseudo-random numb ers generation functions, memory allocation, process control functions <stdnoreturn.h> C11 For specifying non-returning functions. <string.h> Defines string handling functions. <tgmath.h> C99 Defines type-generic mathematical functions. <threads.h> C11 Defines functions for managing multiple Threads as well as mutexes and condition variables. <time.h> Defines date and time handling functions

<uchar.h> C11 <wchar.h> NA1 <wctype.h> NA1 s by their types or to

Types and functions for manipulating Unicode characters. Defines wide string handling functions. Defines set of functions used to classify wide character convert between upper and lower case

Three of the header files (complex.h, stdatomic.h, threads.h) are conditional fe atures that implementations need not support. The POSIX standard added several nonstandard C headers for Unix-specific functio nality. Many have found their way to other architectures. Examples include unist d.h and signal.h. A number of other groups are using other nonstandard headers most flavors of Linux have alloca.h and HP OpenVMS has the va_count() function. Documentation On Unix-like systems, the authoritative documentation of the actually implemente d API is provided in form of man pages. On most systems, man pages on standard l ibrary functions are in section 3; section 7 may contain some more generic pages on underlying concepts (e.g. man 7 math_error in Linux). Implementations Unix-like systems typically have a C library in shared library form, but the hea der files (and compiler toolchain) may be absent from an installation so C devel opment may not be possible. The C library is considered part of the operating sy stem on Unix-like systems.[citation needed] The C functions, including the ISO C standard ones, are widely used by programs, and are regarded as if they were no t only an implementation of something in the C language, but also de facto part of the operating system interface. Unix-like operating systems generally cannot function if the C library is erased. By contrast, on Microsoft Windows, the core system dynamic libraries (DLLs) do n ot provide an implementation of the C standard library; this is provided by each compiler individually. Compiled applications written in C are either statically linked with a C library, or linked to a dynamic version of the library that is shipped with these applications, rather than relied upon to be present on the ta rgeted systems. Functions in a compiler's C library are not regarded as interfac es to Microsoft Windows. Many other implementations exist, provided with both various operating systems a nd C compilers. Although there exist too many implementations to list, some popular implementati ons follow: BSD libc, implementations distributed under BSD operating systems. GNU C Library, used in GNU/Linux and GNU/HURD. Microsoft C Run-time Library, part of Microsoft Visual C++ dietlibc, an alternative small implementation of the C standard library (MMU -less) uClibc, a C standard library for embedded Linux systems (MMU-less) Newlib, a C standard library for embedded systems (MMU-less)[3] klibc, primarily for booting Linux systems. EGLIBC, variant of glibc for embedded systems. musl, another lightweight C standard library implementation for Linux system s[4] Bionic, originally developed by Google for the Android embedded system opera ting system, derived from BSD libc. Compiler built-in functions Some compilers (for example, GCC[5]) provide built-in versions of many of the fu

nctions in the C standard library; that is, the implementations of the functions are written into the compiled object file, and the program calls the built-in v ersions instead of the functions in the C library shared object file. This reduc es function call overhead, especially if function calls are replaced with inline variants, and allows other forms of optimization (as the compiler knows the con trol-flow characteristics of the built-in variants), but may cause confusion whe n debugging (for example, the built-in versions cannot be replaced with instrume nted variants). However, the built-in functions must behave like ordinary functions in accordanc e with ISO C. The main implication is that the program must be able to create a pointer to these functions by taking their address, and invoke the function by m eans of that pointer. If two pointers to the same function are derived in two di fferent translation unit in the program, these two pointers must compare equal; that is, the address comes by resolving the name of the function, which has exte rnal (program-wide) linkage. Linking, libm Under Linux and FreeBSD,[6] the mathematical functions (as declared in math.h) a re bundled separately in the mathematical library libm. If any of them are used, the linker must be given the directive -lm. Detection According to the C standard the macro __STDC_HOSTED__ shall be defined to 1 if t he implementation is hosted. A hosted implementation has all the headers specifi ed by the C standard. An implementation can also be freestanding which means tha t these headers will not be present. If an implementation is freestanding, it sh all define __STDC_HOSTED__ to 0. Concepts, problems, workarounds Buffer overflow vulnerabilities Some functions in the C standard library have been notorious for having buffer o verflow vulnerabilities and generally encouraging buggy programming ever since t heir adoption.[7] The most criticized items are: string-manipulation routines, including strcpy() and strcat(), for lack of b ounds checking and possible buffer overflows if the bounds aren't checked manual ly; there are now alternative routines, such as strncpy() and strncat() string routines in general, for side-effects, encouraging irresponsible buff er usage, not always guaranteeing valid null-terminated output, linear length ca lculation;[8] printf() family routines, for spoiling the execution stack when the format s tring doesn't match the arguments given. This fundamental flaw created an entire class of attacks: format string attacks. gets() and scanf() I/O routines, for lack of (either any or easy) input leng th checking Except the extreme case with gets(), all the security vulnerabilities can be avo ided by introducing auxiliary code to perform memory management, bounds checking , input checking, etc. This is often done in form of wrappers that make standard library functions safer and easier to use. This dates back to as early as The P ractice of Programming book by B. Kernighan and R. Pike where the authors common ly use wrappers that print error messages and quit the program if an error occur s. Threading problems, vulnerability to race conditions The mktemp() and strerror() routines are criticized for being thread unsafe and otherwise vulnerable to race conditions. Error handling

The error handling of the functions in the C standard library is not consistent and sometimes confusing. This can be fairly well summarized by the Linux manual page math_error which says: The current (version 2.8) situation under glibc is messy. Most (but not all) functions raise exceptions on errors. Some also set errno. A few functions set errno, but don't raise an exception. Very few functions do neither. Standardization The original C language provided no built-in functions such as I/O operations, u nlike traditional languages such as COBOL and Fortran.[citation needed] Over tim e, user communities of C shared ideas and implementations of what is now called C standard libraries. Many of these ideas were incorporated eventually into the definition of the standardized C language. Both Unix and C were created at AT&T's Bell Laboratories in the late 1960s and e arly 1970s. During the 1970s the C language became increasingly popular. Many un iversities and organizations began creating their own variants of the language f or their own projects. By the beginning of the 1980s compatibility problems betw een the various C implementations became apparent. In 1983 the American National Standards Institute (ANSI) formed a committee to establish a standard specifica tion of C known as "ANSI C". This work culminated in the creation of the so-call ed C89 standard in 1989. Part of the resulting standard was a set of software li braries called the ANSI C standard library. POSIX standard library Main article: C POSIX library POSIX (and SUS) specifies a number of routines that should be available over and above those in the C standard library proper; these are often implemented along side the C standard library functionality, with varying degrees of closeness. Fo r example, glibc implements functions such as fork within libc.so, but before NP TL was merged into glibc it constituted a separate library with its own linker f lag argument. Often, this POSIX-specified functionality will be regarded as part of the library; the C library proper may be identified as the ANSI or ISO C lib rary. Ongoing work The ISO C committee published Technical reports TR 24731-1 and is working on TR 24731-2 to propose adoption of some functions with bounds checking and automatic buffer allocation, correspondingly. The former has met severe criticism with so me praise,[9][10] the latter received mixed responses. Despite this, TR 24731-1 has been implemented into Microsoft's C standard library and its compiler issues warnings when using old 'insecure' functions. The C standard library in other languages Some languages include the functionality of the standard C library in their own libraries. The library may be adapted to better suit the language's structure, b ut the operation semantics are kept similar. The C++ language, for example, incl udes the functionality of the C standard library in the namespace std (e.g., std ::printf, std::atoi, std::feof), in header files with similar names to the C one s (cstdio, cmath, cstdlib, etc.). Other languages that take similar approaches a re D and the main implementation of Python known as CPython. In the latter, for example, the built-in file objects are defined as "implemented using C's stdio p ackage",[11] so that the available operations (open, read, write, etc.) are expe cted to have the same behavior as the corresponding C functions. Comparison to standard libraries of other languages The C standard library is small compared to the standard libraries of some other languages. The C library provides a basic set of mathematical functions, string

manipulation, type conversions, and file and console-based I/O. It does not inc lude a standard set of "container types" like the C++ Standard Template Library, let alone the complete graphical user interface (GUI) toolkits, networking tool s, and profusion of other functionality that Java provides as standard. The main advantage of the small standard library is that providing a working ISO C envir onment is much easier than it is with other languages, and consequently porting C to a new platform is relatively easy.