Chapter Contents

Previous

Next
Developing Applications for Use with UNIX System Services OS/390

POSIX Conformance

The POSIX.1 standard specifies three levels of conformance:

Strictly Conforming POSIX.1 Applications
A strictly conforming C language POSIX.1 application uses only those facilities described in ISO/IEC 9945 and the ISO C language Standard.

Conforming POSIX.1 Applications
There are two categories for this type of conformance:

Conforming POSIX.1 Applications Using Extensions
This type of application uses documented, nonstandard language extensions that are consistent with the POSIX.1 standard. An example of this type of application would be a program that uses the POSIX.1 interface but also uses the SAS/C Socket Library for TCP/IP.

While SAS/C supports the compilation and execution of strictly conforming POSIX.1 programs, it is also intended to support mixed-mode programming. That is, SAS/C Release 6.00 supports the production of applications that combine POSIX functionality, such as pipes and directories, with traditional OS/390 and SAS/C functionality like VSAM. SAS/C is also flexible about how POSIX and non-POSIX features can be combined. UNIX oriented programs can be written with small nonportable sections to exploit OS/390 features, and OS/390 oriented programs can be written which exploit POSIX functionality when appropriate.


Strictly Conforming POSIX Programs

A POSIX program is strictly conforming if it uses only ISO/ANSI and POSIX standard library features and does not depend on any undefined or implementation-defined behavior. If you want a program to strictly conform to the POSIX.1 standards, you should define the feature test macro _POSIX_SOURCE before including any standard header file. (One way to define this symbol is using the define compiler option.) When _POSIX_SOURCE is defined, the only declarations included in standard header files are those of standard symbols. This ensures that any symbols defined by your application will not conflict with any non-POSIX extensions defined in the standard header files.

The symbol _POSIX1_SOURCE can be defined to the value 2 to define a program that is strictly conforming except for its use of features from the POSIX.1a draft standard. If _POSIX1_SOURCE is defined to 2, then _POSIX_SOURCE need not be defined.


POSIX Programs with Extensions

Many programs use POSIX functionality but are not intended to be strictly conforming. For instance, a socket application cannot be strictly conforming, since sockets are not defined by the POSIX.1 or POSIX.1a standard. If the feature test macro _POSIX_SOURCE is defined, then critical declarations (for instance, the type fd_set ) will be omitted from headers like <sys/types.h> , which will cause a socket application to fail to compile.

SAS/C Release 6.00 defines the feature test macro _SASC_POSIX_SOURCE to specify POSIX functionality plus SAS/C functionality. If the symbol _SASC_POSIX_SOURCE is defined before inclusion of the first system header file, then ISO/ANSI and POSIX header files will define ISO/ANSI and POSIX functionality, plus SAS/C extensions. If you define one of _POSIX_SOURCE or _POSIX1_SOURCE as well as _SASC_POSIX_SOURCE , the standard feature test macro has precedence, that is, SAS/C extensions will not be defined.

If you do not define any feature test macro, then POSIX header files may include definitions of SAS/C extensions. However, ISO/ANSI header files will define only ISO/ANSI sanctioned symbols. Therefore, if you want to use POSIX functionality defined in ISO/ANSI header files (for example, the fdopen routine declared in <stdio.h> ), you should define a feature test macro.

Note that the preferred method of defining the _SASC_POSIX_SOURCE feature test macro is to specify the posix option at compile time.

For more information about feature test macros and the SAS/C Library header files, refer to Chapter 1, "Introduction to the SAS/C Library," in the SAS/C Library Reference, Volume 1.


Portability Considerations

The POSIX.1 standard is designed to facilitate the portability of programs in source form; however, compliance with the standard does not guarantee programs will be completely portable. Dealing with ASCII to EBCDIC character translation is just one of the many issues you should be familiar with if you are developing POSIX applications that will be ported to a platform other that the IBM System/370. Refer to the discussion of data interchange formats in The POSIX.1 Standard: A Programmer's Guide for a detailed treatment of this subject.


Chapter Contents

Previous

Next

Top of Page

Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.