I'm a little confused by "C standard lib" and "C POSIX lib", because I found that, many header files defined in "C POSIX lib" are also part of "C standard lib".
So, I assume that, "C standard lib" is a lib defined by ANSI C organization, and there are different implementation on different platforms (Win32/Unix-like), and "C POSIX lib" is just a implementation for "C standard lib" on Unix-like OSes, right?
But "C POSIX lib" contains some headers not specified in "C standard lib", such as <sys/types.h>, <sys/wait.h>, and <pthread.h>.
Take <pthread.h> as an example, I presume its "C standard lib" counterpart is <threads.h>, then if I want to write a multi-threaded program on Linux, which header file should I include, <pthread.h> or <threads.h>?
POSIX is a superset of the standard C library, and it's important to note that it defers to it. If C and POSIX is ever in conflict, C wins.
Sockets, file descriptors, shared memory etc. are all part of POSIX, but do not exist in the C library.
pthread.h is used for POSIX threads and threads.h is a new header for C11 and is part of the C library. Perhaps pthreads will be deprecated sometime in the future in favor of the C ones, however you probably can't count on C11 to have widespread deployment yet. Therefore if you want portability you should prefer pthreads for now. If portability is not a concern, and you have C11 threads available, you should probably use those.
The C POSIX library is a specification of a C standard library for POSIX systems. It was developed at the same time as the ANSI C standard. Some effort was made to make POSIX compatible with standard C; POSIX includes additional functions to those introduced in standard C.
POSIX 7 quote
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap01.html#tag_14_01
1.1 Relationship to Other Formal Standards
Great care has been taken to ensure that this volume of POSIX.1-2008 is fully aligned with the following standards:
ISO C (1999)
ISO/IEC 9899:1999, Programming Languages - C, including ISO/IEC 9899:1999/Cor.1:2001(E), ISO/IEC 9899:1999/Cor.2:2004(E), and ISO/IEC 9899:1999/Cor.3.
Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2008. Some functions and headers included within this volume of POSIX.1-2008 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2008 and the ISO C standard is unintentional.
I have listed some major API extensions at: I never really understood: what is POSIX?
ANSI C is still alive, I think: ANSI C is inherited and extended by ISO C, Cxx. POSIX have been obeying ANSI C absolutely."
We can write ANSI C on Windows, Unix-Like, embedded device easily; but Cxx, or POSIX may have issue.
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.
I'm a little confused by "C standard lib" and "C POSIX lib", because I found that, many header files defined in "C POSIX lib" are also part of "C standard lib".
So, I assume that, "C standard lib" is a lib defined by ANSI C organization, and there are different implementation on different platforms (Win32/Unix-like), and "C POSIX lib" is just a implementation for "C standard lib" on Unix-like OSes, right?
But "C POSIX lib" contains some headers not specified in "C standard lib", such as <sys/types.h>, <sys/wait.h>, and <pthread.h>.
Take <pthread.h> as an example, I presume its "C standard lib" counterpart is <threads.h>, then if I want to write a multi-threaded program on Linux, which header file should I include, <pthread.h> or <threads.h>?
POSIX is a superset of the standard C library, and it's important to note that it defers to it. If C and POSIX is ever in conflict, C wins.
Sockets, file descriptors, shared memory etc. are all part of POSIX, but do not exist in the C library.
pthread.h is used for POSIX threads and threads.h is a new header for C11 and is part of the C library. Perhaps pthreads will be deprecated sometime in the future in favor of the C ones, however you probably can't count on C11 to have widespread deployment yet. Therefore if you want portability you should prefer pthreads for now. If portability is not a concern, and you have C11 threads available, you should probably use those.
The C POSIX library is a specification of a C standard library for POSIX systems. It was developed at the same time as the ANSI C standard. Some effort was made to make POSIX compatible with standard C; POSIX includes additional functions to those introduced in standard C.
POSIX 7 quote
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap01.html#tag_14_01
1.1 Relationship to Other Formal Standards
Great care has been taken to ensure that this volume of POSIX.1-2008 is fully aligned with the following standards:
ISO C (1999)
ISO/IEC 9899:1999, Programming Languages - C, including ISO/IEC 9899:1999/Cor.1:2001(E), ISO/IEC 9899:1999/Cor.2:2004(E), and ISO/IEC 9899:1999/Cor.3.
Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2008. Some functions and headers included within this volume of POSIX.1-2008 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2008 and the ISO C standard is unintentional.
I have listed some major API extensions at: I never really understood: what is POSIX?
ANSI C is still alive, I think: ANSI C is inherited and extended by ISO C, Cxx. POSIX have been obeying ANSI C absolutely."
We can write ANSI C on Windows, Unix-Like, embedded device easily; but Cxx, or POSIX may have issue.
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".
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 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).