Conforming to standards

The header files supplied with the C library provide the proper declarations for the functions and for the number and types of arguments used with them. Constant values used in conjunction with the functions are also declared. The files can usually be included in any order, although individual function descriptions show the preferred order for specific headers.

If you want to conform to a given language standard, you can use the -std=language option for qcc. This option can cause certain portions of the header files to be omitted, which is likely to cause problems because functions that are defined by POSIX or that are specific to QNX Neutrino won't be defined.

You can then use the qcc -D option to define feature-test macros to specify the portions that you want to include. Here are the most commonly used feature-test macros:

_POSIX_C_SOURCE=version

Include those portions of the header files that relate to the given POSIX standard. For example, _POSIX_C_SOURCE=200809L specifies the IEEE Standard Portable Operating System Interface for Computer Environments - POSIX 1003.1-2008.

_FILE_OFFSET_BITS=64

Make the libraries use 64-bit file offsets.

_LARGEFILE64_SOURCE

Include declarations for the functions that support large files (those whose names end with 64).

_QNX_SOURCE

Include everything defined in the header files. This is defined by default if you don't specify a language standard.

Feature-test macros may be defined on the command line, or in the source file before any header files are included. The latter is illustrated in the following example, in which a POSIX-conforming application is being developed.

#define _POSIX_C_SOURCE 200809L
#include <limits.h>
#include <stdio.h>
   …
#if defined(_QNX_SOURCE)
  #include "non_POSIX_header1.h"
  #include "non_POSIX_header2.h"
  #include "non_POSIX_header3.h"
#endif

You can also set the POSIXLY_CORRECT environment variable to 1. This environment variable is used by Unix-style operating systems to alter behavior to comply with POSIX where it's different from the OS's default behavior. It's a de facto standard that isn't defined by POSIX.

For example, if POSIXLY_CORRECT is set, functions that check the length of a pathname do so before removing any redundant . and .. components. If POSIXLY_CORRECT isn't set, the functions check the length after removing any redundant components.