I sometimes hear people using the terms "libc" and "C standard library" interchangeably. I understand that "libc" is the name (or part of the names) of many popular C standard library implementations. My guess is that because of the widespread use of these implementations, people started referring to the C standard library in general as "libc" although it is not an official name.
Is it correct to refer to the C standard library as "libc"?
I always thought that "libc" just happens to be the name (or part of the names) of many popular C standard library implementations.
This is correct. "libc" is the name of some implementations of the C Standard Library.
As an example of a C Standard Library implementation that is not named "libc," the Microsoft C Standard Library implementation is a part of the "C Run-Time Libraries," usually referred to as the "CRT."
Is it correct to refer to the C standard library as "libc"?
The C Standard Library is not named "libc," so using that term to refer to it generically (and not to a particular implementation) would be incorrect. That said, in most contexts, if you did use the term "libc" to refer to the C Standard Library, you are still likely to be understood.
"libc" is indeed the name of the implementation. It often includes functions that are not part of the C standard, and might not include functions that are part of the C standard. (A common case of the latter is the Standard C math functions being split into a separate "libm".)
'libc' refers to the C standard library. However, the libc has several implementations :
glibc : an implementation of libc written for the GNU Project
klibc : a minimalistic subset implementation of the libc
...
LibC (http://www.gnu.org/s/libc/) is one particular implementation of the C library standard (http://en.wikipedia.org/wiki/C_standard_library#ISO_Standard).
Related
Recently I've read "Extreme C Programming" book and often heard that
C is a Standard
I know, C is standardized by ANSI. But what does it really mean? Is this is about keywords, supported functions or headers?
It means that there is international standardization in the form of a document ISO/IEC 9899:2018 1) stating how compilers and applications should behave. ISO is an international collaboration, consisting of working groups that take input from national standardization institutes such as ANSI/INCITS in USA. So saying that C is standardized by ANSI is wrong unless you happen to live in USA, where the local name for the standard is INCITS/ISO/IEC 9899:2018.
The whole language is specified in this document: terms, behavior, keywords, operators, environment considerations, certain libraries and so on.
1) The official standard costs money to obtain. For student/hobbyist purposes, you can download a draft version of the standard for free though, such as the C11 draft.
If the sentence indeed refers to C being ANSI/ISO standardized, it refers to a lot of things, including your "keywords, supported functions or headers". The ISO C standard defines:
The preprocessor directives (defines and includes).
The syntax (the grammar, the formal structure): The keywords and other building blocks of the language (literals, operators, identifier syntax) and how these can be combined to expressions and statements in order to form a syntactically correct C program.
The semantics of a program (which grammatically correct constructs are allowed, and what is their meaning).
The C Standard Library (malloc, printf, memcpy etc.). The "user facing" part of that library are the headers (stdio.h, string.h etc.) which name and describe the functions available in the standard library. The "system facing" part of the standard library is the actual compiled code of those functions, typically in the form of library files in a platform specific format with platform specific names in platform specific locations such as libc.a on a gcc/linux system. Because the standard library is so commonly used by normal programs, no special effort must be made to link to it: The linker does that automatically. (You still need to include the proper header file though to let the compiler know about the function names and the arguments you want to use.)
Saying that C is a "standard" can have both meanings: The ISO standardization detailed above, but also the fact that C, compared to assembler, is an abstraction layer that shields a program from peculiarities of the underlying hardware, for example is word length, its endianness, signedness of its character type etc. The interaction with the "system" a program is running on is abstracted through the aptly named "Standard Library".
A well-written C program runs without or with only minor modification on a wide variety of platforms. In this sense C was a de-facto "standard" for programming for years before its formal ISO standardization at the end of the 1980s, much in the sense that *nix in one of its flavors has become a de-facto standard for server operating systems.
Addendum: After browsing the accessible part of the book that inspired your question I can say with confidence that the author indeed addresses both meanings of "standard": He talks about the different ISO C standard versions, dedicating an entire chapter to C 2018; but he also says the following, on "54% of sample" (I cannot see a page number there; emphasis by me):
The size of a pointer depends on the architecture rather than being a specific C concept. C doesn't worry too much about such hardware-related details, and it tries to provide a generic way of working with pointers and other programming concepts. That is why we know C as a standard.
I know, C is standardized by ANSI
C was standardized by ANSI in 1989 (aka C89).
It was then globally adopted by ISO/IEC JTC1/SC22 Programming Languages in 1990 as ISO/IEC 9899:1990 (aka C90).
Working Group 14 (WG14) of SC22 have subsequently evolved the C Standard as:
ISO/IEC 9899:1990 (aka C90)
ISO/IEC 9899:1990/AMD1:1995 (aka C95)
ISO/IEC 9899:1999 (aka C99)
ISO/IEC 9899:2011 (aka C11)
ISO/IEC 9899:2018 (aka C18 - although sometimes called C17 as __STDC__ is 201710L)
ISO/IEC 9899:202x (aka C2x) is pending...
There were a couple of TCs too...
As a Standard it has requirements for conformance.
Based on the articles I've read on wikipedia and other sources, I've learnt that operating systems like the ones based on UNIX implement the POSIX-API in C. Moreover, I'm yet to find a POSIX-compliant operating system that implements the POSIX-functionalities in any language other than C.
So, does the POSIX-standard require it's specifications to be implemented in the C language only? Can someone implement the POSIX-functionalities for their own(self-made) operating systems in any other programming language like (pure)Rust and get that operating system certified as a POSIX-compliant OS?
It is highly unlikely anybody will ever use header definitions other than for C/C++ again, which are necessary to comply with the standard.
So while technically not necessary, it is practically a necessity or you need to simulate C header behavior from another language + c99 by ISO specification.
"The C-language Development utility c99 shall be supported." (ISO C standard)
https://pubs.opengroup.org/onlinepubs/9699919799/
It is however possible and often practical to conform to the POSIX System Interfaces(what people usual refer to as POSIX-API) and parts of "Shell and Utilities".
To that regard POSIX is "flawed", because it has a "language-lockin".
How one can include his/her own programming functions to standard C (ANSI C) library? And any one who is learning or working on C language able to use those functions anywhere anytime, no need of development in general.
Example : someone developed function named "FunFun()" and assume it does fantastic work for most programmers. so how anyone can access this "FunFun" function without developing and just including standard library?
The sane way to approach it would be to develop a 3rd party library and make it available over the internet through open source, Github etc.
The GNU C dialect is one such example, which is a collection of non-standard compiler extensions used by the GCC compiler. One could join the GCC open source group and try to get the new function added there. It would still not be standard library C, but the GCC extensions are often an inspiration to the C standard and several of them (designated initializers, flexible array members, anonymous struct/union etc) have been adopted into the language itself with the C99 and C11 standards. One of the purposes for GNU C is actually to serve as an experimental playground where new languages features can be tried out live.
If you truly wish to add a new function to the actual C standard library, you would have to join the ISO working group and convince them that the function should be added to the language. Or alternatively find a member of the committee and convince them to speak in favour of the new function.
All this of course assuming you are a C programming veteran, or otherwise nobody will likely take you seriously.
Your question can't be answered because it's based on several wrong assumptions.
Things like stdlib.h are not libraries. They are header files intended to be included in your program. Including means the contents are literally pasted into your program at the point of inclusion before the actual compilation happens. They are typically used for declaring functions, types, global variables etc a library provides. The actual library is then linked against after compilation.
There's no such thing as the C library as well as there's no such thing as the C compiler. c is a language that is specified in an open standard (if you're interested, here's the last draft of the latest standard version C11). There are many actual implementations and a complete implementation consists of at least a compiler and a standard library. You can of course implement your own standard library. It's a lot of work to have it really conform to the standard (you would have to implement printf() and scanf() correctly, for example). With your own standard library, you can also include your own extensions, but this would only mean people using your standard library (instead of e.g. glibc on a GNU system) could directly use them.
For having a function available on any implementation of C, it would be necessary to have the C Standard specify it. You won't get a new function in the standard without some very good reasoning.
So if you want to make your own function available to others, do what everyone does and just implement it in your own library. Users can download it, include its headers and link against it.
I will give an example from The GNU C Library documentation:
13.1 Opening and Closing Files
This section describes the primitives for opening and closing files
using file descriptors. The open and creat functions are declared in
the header file fcntl.h, while close is declared in unistd.h.
My question is:
Can unistd.h and fcntl.h be considered as Standard C? As far as I know, they should be part of the Posix standard?
Can we say C Standard Library = Posix functions + C API? I am confused because Wikipedia page for C Standard Library does not include unistd.h but the GNU C Library documentation includes it?
No, unistd.h, fcntl.h, etc, are not standard C.
In general, standard C doesn't include functions that deal with low level file manipulation. For example, fopen, fread, and fwrite are part of standard C library. While POSIX open, read, write functions are not standard C.
As far as I can see, in C11 standard, there is no unistd.h and fcntl.h. So, strictly speaking, they are not part of the C standard.
When it comes to the implementation part, the GNU C library (glibc) is one of them. From the wiki page
glibc provides the functionality required by the Single UNIX Specification, POSIX (1c, 1d, and 1j) and some of the functionality required by ISO C11, ISO C99, Berkeley Unix (BSD) interfaces, the System V Interface Definition (SVID) and the X/Open Portability Guide (XPG), Issue 4.2, with all extensions common to XSI (X/Open System Interface) compliant systems along with all X/Open UNIX extensions.
In addition, glibc also provides extensions that have been deemed useful or necessary while developing GNU.
So, as a part of the POSIX standard, they are available in glibc.
Reference: Check the C11 standard draft version here.
I am currently learning C. I understand that many common functions, like printf and scanf are not actually part of the C language -- they are part of the "standard library" of functions.
My question is, why aren't such functions built into the language? Is it a philosophical/design consideration? A matter of efficiency when compiling programs? A necessity in order to act as a "middle layer" to ensure compatibility with different operating systems? Something else entirely?
They are part of C. A C implementation consists of a compiler and a library (and other components, like a linker).
The C core language includes facilities that make it possible to write library code that can be used by other programs. The standard library portion of the standard specifies a library that can be implemented using the facilities defined in the core language.
Some languages do have things like a print command built into the language. C's facilities for writing and invoking library code written in C are powerful enough that that's not necessary.
Furthermore, most of the library is optional for "freestanding" implementations (mostly for embedded systems). There are implementations that support the full core language but that don't provide most of the C standard library.
And a compiler and library can be provided separately. For example, gcc is a compiler; it's commonly used with different library implementations on different systems (GNU libc on Linux, "newlib" on Cygwin, the Microsoft library on Windows with MinGW, and so forth). Mixing and matching like that would be much more difficult if the library were integrated into the core language.
The C language standard (the link is to the newest freely available draft) defines C. Section 6 defines the core language; section 7 defines the standard library.
The thing is that standard allows two kinds of conforming implementation: hosted and freestading, see N1570 4/p6:
The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any
strictly conforming program. A conforming freestanding implementation
shall accept any strictly conforming program that does not use complex
types and in which the use of the features specified in the library
clause (clause 7) is confined to the contents of the standard headers
<float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>,
<stddef.h>, <stdint.h>, and <stdnoreturn.h>. A conforming implementation may have
extensions (including additional library functions), provided they do
not alter the behavior of any strictly conforming program.
By such design, where the libraries are organized as standard headers it's convienent to simply "cut-off" some header if it is not supported.
Note that C standard defines all headers along with function for standard C library. It's included in C standard indeed, not separate thing somewhere else.
They're part of the language, they're just not part of the grammar.
Factoring I/O out into a separate function library buys you the following:
The grammar becomes easier to parse;
You can target a wider range of platforms; any I/O foibles are handled by the library functions, not by hacking the code generator;
You can implement only as much as is needed to support the platform (i.e., an embedded controller probably doesn't need to read or write formatted output);