I can't use setenv() from stdlib.h for C99 standard compiler as it is not available. Is there any other function to set an environment variable in C99?
getenv is thus part of the C90 standard which is included in C99 but setenv is only conform to an IEEE standard so it hasn't to be included in strictly standard C99. Moreover, the corresponding IEEE is from 2001.
This means there isn't any standard way of doing this in C99, you have to use platform-specific code to set the env.
On the freebsd man page:
The getenv() function conforms to ISO/IEC 9899:1990 (ISO C90'').
The setenv(), putenv() and unsetenv() functions conforms to IEEE Std
1003.1-2001 (POSIX.1'').
setenv, putenv and so on should be defined on any POSIX system.
If you're using windows, see this other question which talks about _putenv_s.
Related
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.
There is fprintf function in Stdio library.
But how to use it?
The first argument is FILE type.
But I have EFI_FILE_PROTOCOL* File which I got from EFIOpenFile function. How to map to FILE type?
There are hosted environments and freestanding environments.
From the C standard:
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 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.
So in a freestanding environment (like the UEFI environment you are describing) the C standard doesn't require the fprintf() function to be defined/declared and doesn't require the FILE type to be defined either. Therefore you need to code them on your own.
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 have found in http://en.wikipedia.org/wiki/C99 that Pelles C has full support for C99.
However I have doubts.
As probably you know, the GCC project has not yet reached full support for C99. The details in which GCC is conforming or not are very well documented. However, I cannot understand what exactly means that Pelles C is fully conforming.
Is it conforming for every computer and operating system?
For example, GCC (under command line option -std=c99) is compliant with ISO/IEC IEEE 60559 (floating point standard) if the hardware is perfectly compliant.
http://gcc.gnu.org/c99status.html
Is Pelles C concerned with this level of detail?
I don't feel sure about the claims that Pelles C is C99 conforming.
According to this article and Wikipedia, Pelles C has full support for C99 (and C11). So unless you have evidence showing that it doesn't, I think one can say it conforms the C99 standard.
As for the support for IEC 60559 floating-point arithmetic, note that it's only optional in C99 (and in C11):
C99 ยง6.10.8 Predefined macro names
The following macro names are conditionally defined by the implementation:
__STDC_IEC_559__ The integer constant 1, intended to indicate conformance to the
specifications in annex F (IEC 60559 floating-point arithmetic).
__STDC_IEC_559_COMPLEX__ The integer constant 1, intended to indicate adherence to the specifications in informative annex G (IEC 60559 compatible complex arithmetic).
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.