Creating your own header files

In addition to the header files that the z/TPF system provides, you can create your own. This section gives you some general guidelines.

The following items belong in z/TPF header files:
  • Commonly defined constant terms using the #define preprocessor statement. These include:
    • z/TPF constants
    • Bit masks used to test for particular conditions
    • Other uses of the #define statement, such as coding a #define statement for a constant following an #ifndef statement, to make sure the constant is not defined more than once.
  • struct, enum, and union declarations (not definitions, which actually reserve space for the data objects)
  • C macros
  • Entry point prototypes
  • Type definitions (using the typedef facility)
  • Any number of nested #include statements.
The following items do not belong in z/TPF header files:
  • Data object definitions of any type or class
  • Function code of any type.

All data structures that have a corresponding assembler DSECT defined by their own macro reside in their own header files. If you are going to convert existing assembler data macros to C or C++ structures, you need to consider boundary alignment. Boundary alignment is determined by how data types are stored. The following shows how data types are stored and aligned by the C or C++ compiler:

Data type Memory occupied Alignment
char 1 byte byte
int 4 bytes fullword
short int 2 bytes halfword
long int 8 bytes doubleword
float 4 bytes fullword
double 8 bytes doubleword

In C language, using int, short int, long int, float, and double in data structures forces boundary alignment to the next boundary determined by the data type. When these data structures are coded in assembler, the boundaries can differ (unless the assembler version is coded to coincide with the C version). This is a serious problem because it can result in errors that are difficult to diagnose.