What advantages does using #define _POSIX_SOURCE in C confer to my program? Can I access more libraries in my program or I can call some functions which are present directly in C. What is this macro used for?
It allows you to use functions that are not part of the standard C library but are part of the POSIX.1 (IEEE Standard 1003.1) standard. Using the macros described in
feature_test_macros allows you to control the definitions exposed
by the system header files.
As far as I know _POSIX_SOURCE is obsolete and you should use _POSIX_C_SOURCE instead.
For example, if you want to use strndup, you have to use
#define _POSIX_C_SOURCE 200809L
See also
1.3.4 Feature Test Macros
5.12 Posix Variants
man 7 feature_test_macros
Related
(split this off from this question)
The following 3 macros appear in many C source files which try to detect/rely on the availability of POSIX functionality:
_POSIX_SOURCE
_POSIX_C_SOURCE
_POSIX_ (and _POSIX ?)
In the linked-to question it's explained that we're supposed to set _POSIX_C_SOURCE to the POSIX version on which we want to rely (although setting it doesn't guarantee that the functionality will actually be available - that's up to the compiler/OS). Also, while I can set it as the user, it's not clear when others set it themselves (e.g. the compiler / build system). For the other two, I know neither when I should set them nor when others set them.
So, what is the difference in meaning between the three macros? When would each of them be set for me? And why/when should I choose to set one of them over the others, if at all?
Very partial answer (and with thanks to #SomeProgrammerDude):
The POSIX reference tells us that:
The POSIX.1-1990 standard specified a macro called _POSIX_SOURCE. This has been superseded by _POSIX_C_SOURCE.
and in practical terms, the GNU C library manual tells us, for example:
The state of _POSIX_SOURCE is irrelevant if you define the macro _POSIX_C_SOURCE to a positive integer.
and it should probably be the same for other C standard library implementations. So - never use _POSIX_SOURCE yourself, only use _POSIX_C_SOURCE (except if you are on old platforms where the OS and libraries have not seen updates for the past 20 years at least).
_POSIX_ and _POSIX is a Microsoft-Visual-C(++)-specific macro. I am guessing you define it to get MSVC to expose POSIX/POSIX-like functionality. According to this non-authoritative thread on the MinGW mailing list, MSVC no longer uses _POSIX_ (and _POSIX?) as of MSVC2013.
I've gotten myself into having to maintain some C project which should also compile on older platforms. At the moment, for some platforms, the macro _POSIX_C_SOURCE is defined. I was wondering - if it's acceptable to have it defined, should I not just define it always, on all platforms? And perhaps with the highest relevant value?
To generalize, I suppose I'm asking: When and under what conditions should _POSIX_C_SOURCE be used?
_POSIX_C_SOURCE makes different functionality available.
_POSIX_C_SOURCE 1 makes the functionality from the POSIX.1 standart available
_POSIX_C_SOURCE 2 makes the functionality from the POSIX.2 standart available
_POSIX_C_SOURCE 199309L makes the functionality from the POSIX.1b standart available
Higher values like 200809L make more features available. (man 7 feature_test_macros)
In general _POSIX_C_SOURCE is needed if you need strict POSIX compliance
It is safe to define it in every project if you don't care for specific POSIX standard compliance.
In C, what is the correct way to check if a feature macro has any effect?
For example, if configure.ac contains the macro AC_USE_SYSTEM_EXTENSIONS then it will define _GNU_SOURCE on whatever OS. However, if we compile on OSX then _GNU_SOURCE will not have any effect. But on GNU systems it does, so how can I check if _GNU_SOURCE enables a feature, such as qsort_r?
man feature_test_macros says I should not include features.h, since it could be different on every system, meaning I can not use __USE_GNU.
The other option would be to check if __GNUC__ is defined, or possibly if both __GNUC__ and _GNU_SOURCE are defined?
Is it possible to use POSIX functions even in strict std=c89? When I try to compile executable on Linux in strict ANSI C mode, both gcc and clang know nothing about functions like readlink or realpath, though headers are included. Since I have to use POSIX functions even in ANSI C mode, I'm looking for way to do it. I've thought about dlsym, but I don't know which library I'll have to open. Such calls are surrounded with #ifdef's, so they won't rise an alarm on the other system. Cross-platform solution needed. Thanks in advance!
You're looking for "feature-test macros". See the Single Unix Specification, Issue 6: System Interfaces Chapter 2.2, "The Compilation Environment"
Edit:
To quote that page:
The _POSIX_C_SOURCE Feature Test Macro
A POSIX-conforming application should ensure that the feature test macro
_POSIX_C_SOURCE is defined before inclusion of any header.
GCC and clang currently define _POSIX_C_SOURCE for you by default unless one of c89, c99, c11, or any behaviorally equivalent string is passed to the compiler's -std option.
Additionally:
The _XOPEN_SOURCE Feature Test Macro
An XSI-conforming application should ensure that the feature test macro
_XOPEN_SOURCE is defined with the value 600 before inclusion of any header.
This is needed to enable the functionality described in The _POSIX_C_SOURCE
Feature Test Macro and in addition to enable the XSI extension.
In other words, to guarantee your program (a.k.a. application) can use POSIX, either #define _POSIX_C_SOURCE 200112L before any header is included or pass the -D_POSIX_C_SOURCE=200112L option to the compiler. For the XSI functionality, you must define _XOPEN_SOURCE to a value of 600.
There is also a newer version of the Single Unix Specification — Issue 7. Very similar text can be found in Issue 7. The only real differences with respect to the text above are the numbers for _POSIX_C_SOURCE and _XOPEN_SOURCE have been changed.
At least when a combination of gcc and glibc on linux, you can turn on non standard functions (e.g. those defined by posix) with #define's , see man feature_test_macros
e.g. #define _POSIX_C_SOURCE 200809L before including any header files, or by adding it to the compiler arguments:
gcc -std=c99 -D_POSIX_C_SOURCE=200809L ...
I was looking at the man page of sigaction, and I ended up looking at the following line.
sigaction(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE
What do _POSIX_X_SOURCE, _X_OPEN_SOURCE, _POSIX_SOURCE mean? What to do with it?
These are feature test macros. Their purpose is to allow your program to inform the system header files which standards you want it to attempt to conform to, and what extensions you want available.
Without any feature test macros defined, implementations vary a lot in what macros, functions, and type definitions they make visible in their headers. A common practice is to make everything visible by default, which is a problem because "everything" is not very specific, and it's very possible that symbol names used in your program might clash with some of the extensions. Even if they don't clash now, there's no way to know if they will in the future. So the standards (like ISO C and POSIX) put strict requirements on the implementation that it not pollute the applications namespace with names not explicitly defined or reserved in the standards. When you use a feature test macro to request a particular standard, you're asking the implementation to ensure that (1) it provides everything defined in this standard, (2) it doesn't pollute your application's namespace by providing anything not defined in that standard.
A correct program should always explicitly use the right feature test macros for the standard(s) it's written to. The easiest way to do this is putting the right -D argument on the compiler command line (CFLAGS). Adding the #define as the first line in each source file also works. Be aware if you do it in source files though:
The feature test macros must be defined at the top before any system header is included.
It's usually a bad idea to use different feature test macros in different translation units.
As an aside, it's not exactly the same as the other feature test macros, but all modern programs should define _FILE_OFFSET_BITS=64 when built on Linux/glibc to request that off_t be 64-bit for large file support.
Here is a man for Feature macros: http://www.kernel.org/doc/man-pages/online/pages/man7/feature_test_macros.7.html
They will turn on or off some level of standard support in the headers.
E.g. _POSIX_C_SOURCE >= 1 means that POSIX.2-1992 or later should be supported; _X_OPEN_SOURCE means POSIX.1, POSIX.2, and XPG4 are enabled; and for greater values of macro (>=500; >=600; >=700) it will also turn on some variants of SUSv2 v3 or v4 (UNIX 98; 03 or POSIX.1-2008+XSI). And _POSIX_SOURCE is an obsolete way to define _POSIX_C_SOURCE = 1
They're the things you have to #define to get the prototype, and are known as feature test macros.
For example, the following code will susscessfully define the prototype for sigaction:
#define _XOPEN_SOURCE
#include <signal.h>
Including signal.h without that #define (or the others) will not define the prototype.
It is a Feature test macro.
Symbols called "feature test macros" are used to control the visibility of symbols that might be included in a header. Implementations, future versions of IEEE Std 1003.1-2001, and other standards may define additional feature test macros.