Chapter Contents
Previous
Next
Source Code Conventions

Environmental Elements

This section covers the following environmental elements, which affect the SAS/C Compiler's processing of source code:

Source File Sequence Number Handling

The compiler examines the first record in the source file and in each #include file to determine if that file contains sequence numbers. Therefore, you can safely mix files with and without sequence numbers and use the compiler on sequenced or nonsequenced files without worrying about specifying a sequence number parameter.

For a file with varying-length records, if the first four characters in the first record are alphanumeric and the following four characters are numeric, then the file is assumed to have sequence numbers.

For a file with fixed-length records, if the last four characters in the first record are all numeric and the preceding four characters are alphanumeric, then the file is assumed to have sequence numbers.

If a file is assumed to have sequence numbers, then the characters in each record at the sequence number position are ignored. The characters are not treated as part of the program by the compiler, and they are printed in the sequence number position on the listing, rather than where they actually appear in the record.

This algorithm detects sequence numbers or their absence correctly for almost all files, regardless of record type or record length. Occasionally it may cause problems, as in the following examples:

Include-File Processing

Because of the variety of environments in which the SAS/C Compiler executes, and the variety of include-file organizations used by programs of different sorts, the compiler's include-file processing can be quite complex. The implementation was designed to meet the following requirements:

  1. Include files can be stored in any file type readable by the compiler, including OS/390 PDSs (partitioned data sets), CMS minidisks or shared file system files, and UNIX System Services (USS) HFS files.

  2. The user can easily specify the locations where include files reside, in any environment.

  3. The user can choose between UNIX oriented or mainframe oriented search rules.

  4. Provision is made to allow include statements specifying a directory path to be resolved from a file system that does not support directories by means of a header name mapping facility.

The rest of this section presents include-file processing topics in the following order.

  1. Processing in simple OS/390, CMS, and USS applications, in which no include directives specify directory paths.

  2. Processing in applications that specify directory paths in include directives, but where the include files are stored in a mainframe file system (for example, a CMS minidisk).

  3. Processing in applications that access include files from the USS hierarchical file system, or that require more flexibility than provided by the facilities described in the first two sections.


Simple include-file processing under OS/390

On OS/390, the accepted forms for a simple #include directive are as follows: 

#include "member.libddn"
#include "style:pathname"
#include "//[style:]pathname"
#include <member.h>
#include <member>

In the first form, the first part of the filename is interpreted as a member name and the second part as a DDname. For instance, an include of " protos.h " will look in DDname H for a PDS member PROTOS. Note that the DDname H could also reference an USS HFS directory, in which case the compiler includes the file protos.h from that directory. If the member specified is not found in the DDname specified, the compiler processes the directive as if the filename were enclosed in angle brackets. In the example, if the compiler failed to locate " protos.h " , it would attempt to include <protos.h> .

In the second or third form, the filename must be a valid pathname for a call to fopen (see SAS/C Library Reference, Volume 1). In this case, the compiler simply includes the file specified. If the file cannot be opened, the compilation fails.

In the fourth and fifth forms, the first part of the filename is interpreted as a member name, and the rest of the filename, if any, is ignored. The include file is read from the DDname SYSLIB. If the member cannot be found, the compilation fails.

Note that if the underscore character (_) appears in the member or libddn part of an include filename, it is translated to a pound sign (#) wherever it occurs, except when including from an HFS directory. For instance, including " name_1.my_lib " would fetch the member NAME#1 from the PDS referenced by the DDname MY#LIB. Also note that if the member name or libddn name is longer than eight characters, it is truncated.

Simple include-file processing under CMS

On CMS, the accepted forms for a simple #include directive are as follows: 

#include "filename.filetype"
#include "style:pathname"
#include "//[style:]pathname"
#include <member.h>
#include <member>

In the first form, the filename is interpreted as a CMS filename and filetype and located on an ACCESSed minidisk. For instance, an include of " protos.h " will search all ACCESSed minidisks for the file PROTOS H. If the file specified cannot be found, the compiler processes the directive as if the filename were enclosed in angle brackets. In the example, if the compiler failed to locate " protos.h " , it would attempt to include <protos.h> .

In the second and third forms, the filename must be a valid pathname for a call to fopen (see SAS/C Library Reference, Volume 1). In this case, the compiler simply includes the file specified. If the file cannot be opened, the compilation fails.

In the fourth and fifth forms, the first part of the filename is interpreted as a member name, and the rest of the filename, if any, is ignored. The include file is read from the currently GLOBALed MACLIBs. If the member cannot be found, the compilation fails.

Note that if a member name or filename component is longer than eight characters, it is truncated.

Simple include-file processing under the USS shell

Under the USS shell, the accepted forms for a simple #include directive are as follows: 

#include "pathname"
#include "//[style:]pathname"
#include <member.h>

In the first form, the filename is interpreted as an HFS filename in the same directory as the including file. For instance, an include of " protos.h " in the source program will search the source directory for the file protos.h . If the file specified cannot be found, the compiler processes the directive as if the file were enclosed in angle brackets. In the example, if the compiler failed to locate " protos.h " , it would attempt to include <protos.h> .

In the second form, the filename must be a valid pathname for a call to fopen (see SAS/C Library Reference, Volume 1). In this case, the compiler simply includes the file specified. If the file cannot be opened, the compilation fails.

In the third form, the first part of the filename is interpreted as a member name, and the rest of the filename, if any, is ignored. The member is read from the site-defined OS/390 PDS containing the standard header files. If the member cannot be found, the compilation fails.

Note that complex applications may require the use of the ipath compiler option to augment these simple search rules. This option is discussed in Complete include processing.

Header file mapping

Many existing programs written for other environments such as UNIX contain #include directives which reference directories or which have long filenames that are not unique within the first eight characters. Since the OS/390 and CMS file systems do not support directories or filename components longer than eight characters, these files could not be stored on the mainframe without being renamed and/or reorganized. Header file mapping was developed for the SAS/C Compiler to allow the portable source for these applications to be used despite the deficiencies of the mainframe file systems.

SAS/C allows a user to define a lookup table to the compiler, which defines a mapping from include filenames as specified in the program to actual filenames. Because the table is external to the program, the program's source need not be changed, and the same table can be used for multiple programs. There are two header mapping files: one for system (angle-bracketed) include files and one for user (double-quoted) include files.

Locating the header map

Before opening any include file, the compiler attempts to open a $$HDRMAP file. If the include file is a system header file, the header map file is found like <$$hdrmap.h> (that is, on OS/390 it is the $$HDRMAP member of SYSLIB, and on CMS it is the $$HDRMAP member of the GLOBALed MACLIBs). Similarly, if the include file is a user include file, the compiler looks for $$HDRMAP as if it were included as " $$hdrmap.h " . Note that on OS/390 the libddn part of the original user include filename is ignored, and $$HDRMAP is always fetched from the DDname H.

Note that $$HDRMAP is processed for any include directive, even if the filename does not include a directory specification.

Format of the header map

The $$HDRMAP file consists of one or more mapping lines and comments. A comment is any line whose first non-white-space character is a pound sign (#). A mapping line is a line containing two strings separated by blanks or tabs and optionally followed by comments. For example: 

X11/AtomMgr.h        XATMGR.H       X11R5 header

The first name is the expected header filename. The filename from a compiled #include directive is compared with the header name in each $$HDRMAP line until a matching line is found. The names must match exactly. For example, "./X11/AtomMgr.h" and "X11/AtomMgr.h" are not considered to match. If the compiled filename does match the first name of a header map line, the compiler replaces it with the second string on the line and proceeds to search for that file using the rules described in Include-File Processing. Thus, on OS/390, a #include directive for "X11/AtomMgr.h" would attempt to include the member XATMGR in the DDname H.

Note that a target filename in the $$HDRMAP file should not be bracketed or quoted. The type of file (system or user) is always assumed to be the same as in the original #include directive. Also note that if the search for a user header file (whether the name is mapped or not) fails, the system $$HDRMAP file is used to map the name before the system header file location is searched. Therefore, the order of steps for a user header file is as follows:

  1. Look for a matching entry in the user $$HDRMAP. If found, replace the original name by the mapped name.

  2. Search the user header file location for the filename resulting from step 1.

  3. If that fails, look for an entry matching the original name in the system $$HDRMAP. If found, replace the original name by the mapped name.

  4. Search the system header file location for the filename resulting from step 3.


Header map example

Assume the following system header file map (SYSLIB($$HDRMAP) on OS/390): 

X11/AtomMgr.h                XATMGR.H
X11/Xlibos.h                 XLIBOS.H
../mydir/george.h            GEORGE.MYDIR

and the following user header file map (H($$HDRMAP) on OS/390): 

MyVeryLongName.h             MVLN.H
../mydir/myfile.h            MYFILE.MYDIR

Then, the following #include directives would be processed as follows:

#include " ../mydir/myfile.h "
The second line of the user header map would be located, and the compiler would attempt to read the include file from member MYFILE of the DDname MYDIR.

#include " ../mydir/george.h "
No match is found in the user header file map. Assuming that there is no member GEORGE in the file referenced by DDname H, the system map is then searched and the third line is a match. Because the match was found in the system map, GEORGE.MYDIR is treated as a system header filename, and the compiler attempts to read member GEORGE of DDname SYSLIB.

#include <X11/Xlibos.h>
The compiler searches the system header file map and finds the second line. The compiler reads member XLIBOS of DDname SYSLIB.


#chain Command

#chain FILENAME

When the #chain command is specified in a $$HDRMAP file, the header-map lookup uses the #include processing rules specified on this compilation to locate the file named FILENAME. It uses system include rules when processing system $$HDRMAP files and user include rules for user defined $$HDRMAP files.

Any header-map entries found in the file will be inserted in the list at the point of the #chain command.

A file that is processed using a #chain can #chain other files. If the file named on the #chain cannot be located or opened using the include search rules, the #chain is ignored and processing continues.

For example, in a user include $$hdrmap.h, you could have 

foo.h bar.h
harry.h george.h
#
# Go get the mappings for the current project.
#

#chain //DDN:PROJECT(MAPPINGS)

alice.h betty.h

If the DDN "PROJECT" was defined so that MAPPINGS contained 

somebiglongname.h sbln.h

Then the header map list would be : 

foo.h --> bar.h
harry.h --> george.h
somebiglongname.h --> sbln.h
alice.h --> betty.h


Complete include processing

This section describes in detail the entirety of the compiler's header file processing. This section is most relevant if you have header files in the USS hierarchical file system, but it may also be relevant to other complicated applications.

To deal with the complexities introduced by HFS directories and to provide a high level of compatibility with UNIX include-file processing, the compiler offers the ipath and usearch options. Additionally, on CMS the _HEADERS environment variable provides additional flexibility for users of the CMS shared file system. Refer to Using Environment Variables to Specify Defaults for information on the _HEADERS environment variable.

The usearch option specifies "UNIX search rules," which is a rearrangement of the compiler's normal methods of processing for greater UNIX compatibility. usearch is the default when you compile under the USS shell, but it may be specified for compiles from other environments. The ipath option allows you to specify one or more locations to be searched for header files. These are normally HFS directories, but they could also be PDS names or CMS shared file system directories.

If the usearch option is not in effect, the order of include processing for a #include of a user (double-quoted) header file is as follows. (Note that if any step locates the file, the remaining steps are not performed.)

  1. A $$HDRMAP lookup is performed to see if the filename should be mapped to another name.

  2. If the filename was specified with a style prefix, the compiler attempts to open the file specified. Similarly, if the compiler is running from the USS shell and the include file is specified using an absolute pathname (one beginning with a slash), the compiler attempts to open the file specified. In either case, if this fails, no further steps are attempted.

  3. The locations specified by ipath options are searched for the header file, in the order in which they were specified.

  4. If the file containing the include directive was obtained from an HFS directory, the compiler searches this directory.

  5. If the compiler is running under the USS shell, it searches the current directory.

  6. The compiler looks in the normal, system-dependent place for the header file. On OS/390, it transforms the filename into an OS/390 member name and DDname, as described in Simple include-file processing under OS/390, discarding any directory specification. On CMS, this search takes place in two stages:
    1. If the _HEADERS environment variable was defined, as described in Specifying Shared File System Directories, the compiler searches each shared file system directory specified by _HEADERS for the required file.

    2. Any directory specification in the filename is discarded, and all ACCESSed minidisks are searched for the file.

  7. The compiler attempts to locate the file as a system header file.

If the usearch option is not in effect, the order of processing for a system (bracketed) include file is as follows. (Note that if any step locates the file, the remaining steps are not performed.)

  1. A $$HDRMAP lookup is performed to see if the filename should be mapped to another name.

  2. If the filename was specified with a style prefix, or if the compiler is running under the shell and an absolute pathname was specified, the compiler attempts to open the file specified. If that fails, no further steps are attempted.

  3. The compiler searches each location specified via the INCLUDE environment variable. (This facility is defined for use in library development and is not recommended as a customer interface.)

  4. The compiler looks for the header file as a member of SYSLIB on OS/390 or of the GLOBAL MACLIBs on CMS.

If the usearch option is specified to enforce UNIX search rules, the search for a user (double-quoted) include file proceeds as follows. (Note that if any step locates the file, the remaining steps are not performed.)

  1. A $$HDRMAP lookup is performed to see if the filename should be mapped to another name.

  2. If the filename was specified with a style prefix, or if the compiler is running under the shell and an absolute pathname was specified, the compiler attempts to open the file specified. If that fails, no further steps are attempted.

  3. The compiler looks for the header file in the location (HFS directory, OS/390 PDS, CMS minidisk or shared file system directory) containing the file that included this one.

  4. The locations specified by ipath options are searched for the header file, in the order in which they were specified.

  5. The compiler looks in the normal, system-dependent place for the header file. On OS/390, it transforms the filename into an OS/390 member name and DDname, as described in Simple include-file processing under OS/390, discarding any directory specification. On CMS, this search takes place in two stages:
    1. If the _HEADERS environment variable was defined, as described in Specifying Shared File System Directories, the compiler searches each shared file system directory specified by _HEADERS for the required file.

    2. Any directory specification in the filename is discarded, and all ACCESSed minidisks are searched for the file.

  6. The compiler attempts to locate the file as a system header file.

If the usearch option is specified to enforce UNIX search rules, the search for a system (bracketed) include file proceeds as follows. (Note that if any step locates the file, the remaining steps are not performed.)

  1. A $$HDRMAP lookup is performed to see if the filename should be mapped to another name.

  2. If the filename was specified with a style prefix, or if the compiler is running under the shell and an absolute pathname was specified, the compiler attempts to open the file specified. If that fails, no further steps are attempted.

  3. The locations specified by ipath options are searched for the header file, in the order in which they were specified.

  4. The compiler searches each location specified via the INCLUDE environment variable. (This facility is defined for use in library development and is not recommended as a customer interface.)

  5. The compiler looks for the header file as a member of SYSLIB on OS/390 or of the GLOBAL MACLIBs on CMS.

The primary differences between the UNIX ( usearch ) search rules and the ordinary SAS/C ( nousearch ) search rules are the following:

Multibyte Character Support

Multibyte character support enables programs to adapt to different cultures by providing support for large character sets. (See Chapter 10, "Localization," and Chapter 11, "Multibyte Character Functions," in SAS/C Library Reference, Volume 2 for more information.) To support large character sets (for example, the 14,000 or so most commonly used Japanese ideographs), at least 2 bytes are needed to provide encoding for the complete set. An 8-bit byte alone cannot provide the number of distinct values necessary to provide this support.

The ISO/ANSI Standard defines the concepts of multibyte characters and wide characters to support these large character sets. The method of implementation of these concepts is implementation-defined. The compiler has chosen to implement these features compatibly with the EBCDIC DBCS (double-byte character set) definition when the current locale at compile time supports DBCS.

A wide character is a value of type wchar_t , which the compiler defines as unsigned short . If the value is in the range of the char type, it represents a standard EBCDIC character. If the value is outside the range of char , it represents an extended character, such as a character of the Japanese Kanji character set. EBCDIC DBCS constrains each byte of a wide character outside the range of char to have a value between 0x40 and 0xFE.

Wide characters are easy to process in C, but external DBCS data are usually not in this format. The multibyte character string format is more common. A multibyte character string contains a mixture of standard EBCDIC single-byte characters and extended double-byte characters. (This is called a mixed string in EBCDIC DBCS terminology.)

When DBCS support is enabled, the interpretation of the bytes of a multibyte character string is controlled by use of the SO (shift out) and SI (shift in) characters whose values are 0x0E and 0x0F, respectively. At the start of a multibyte string, characters are interpreted as single-byte EBCDIC characters until an SO character is encountered. This causes a transition to the double-byte shift state in which each pair of characters is interpreted as an extended double-byte character. If an SI character is encountered, the single-byte interpretation is resumed, and so on. Thus, the interpretation of individual characters in a multibyte character string is dependent on the current shift state.

When DBCS support is not enabled, all characters are interpreted as standard EBCDIC characters, and no special semantics are associated with SO or SI.

Note that the term multibyte character is used to refer to any character of the extended character set. In particular, standard EBCDIC characters such as A are multibyte characters even though only a single byte is required to represent them.

The following two sections cover aspects of the multibyte character implementation related to compiler support. Chapter 11 in SAS/C Library Reference, Volume 2 covers the library implementation of the multibyte functions.

Control of character types by locale support

The compiler uses the current locale to enable its DBCS support. This is controlled by the environment variable _LOCALE as described in Chapter 10 in SAS/C Library Reference, Volume 2. For example, the locale that needs to be set is the one in use when running the compiler (not when executing the resultant program).

The compiler uses the locale in effect during compilation to enable its DBCS support. This is controlled by the environment variable _LOCALE. Under OS/390 batch, the environment variable is set by including =_LOCALE=DBCS in the compiler's PARM string. In TSO, you can use the PUTENV command to set _LOCALE, if your site makes this command available. Under CMS, assigning the value DBCS to the GLOBALV variable _LOCALE in the CENV group has the same effect. Note that, because GLOBALV variables are shared by all programs, this assignment also affects any C program that uses the default locale during execution. To limit the effect to just the compiler under CMS, you should use an explicit command-line assignment, as you would under OS/390.

Compiler lexical processing

The values assigned to characters are implementation-defined. For all basic characters and other single-byte characters, the values are those given by EBCDIC. For multibyte characters, the values given by the DBCS for the language character set currently enabled are used.

All instances of DBCS in C source are in mixed strings. For string literals (including array initializers) and character constants, an L prefix controls whether or not the type of the literal or constant is based on char or wchar_t .

The ISO/ANSI C Standard allows the following lexical elements to contain multibyte characters (or any other members of the extended character set):


Character constants

There are two kinds of character constants: integral and wide. Wide character constants are prefixed by the letter L. Integral character constants have type int ; wide character constants have type wchar_t . In the SAS/C implementation, wchar_t is an unsigned short .

An integral character constant normally contains only a single character. If more than one character is present, the value of the constant is the value of the integer whose rightmost bytes are those of the constant. (If there are more than four characters, only the four rightmost are used.) For instance, the integral character constant `HI` has the same value as 0xC8C9. Note that use of an integral character constant containing more than one character is not portable.

A wide character constant normally contains only a single multibyte character or escape sequence. If a wide character constant contains more than one, only the rightmost is used. The value of a wide character constant is determined as follows:


String literals

The implementation of string literals and wide string literals is nearly identical to that of character constants. The type of a wide string literal is interpreted as an array of wchar_t . The compiler issues a warning message for attempts to use adjacent string concatenation with different types of string literals and gives the type for the first literal in the concatenation. (The ISO/ANSI Standard treats this as undefined.)

Header filenames

The compiler accepts multibyte sequences in header filenames. The mixed DBCS string is passed to the operating system unchanged.

Array initializers

A wide string literal may be used to initialize an array of elements whose type is wchar_t . Both static and auto array initialization are supported.

Special Character Support

The C language uses a number of special characters. Many IBM mainframe terminals and printers do not supply all of these characters. The compiler provides three solutions to this problem:


Trigraphs sequences

Trigraph sequences are an invention of the C standardization committee. They are intended to serve as replacements for characters in the C character set that do not appear in the ISO 646 character set. See the trigraphs option in Compiler Options for information about trigraphs.

Digraphs

The C language is implemented traditionally using the ASCII character set. The compiler uses EBCDIC, the IBM 370 preferred character set, as its native set. Because some characters used by the C language are not normal EBCDIC characters (that is, they do not appear on many terminal keyboards), alternate representations are available for them. Also, for some characters there is more than one similar EBCDIC character. In such cases, the compiler accepts either.

Digraph Sequences For Special Characters gives alternate representations that the compiler accepts.

Digraph Sequences For Special Characters
C Character EBCDIC Values(s) (hex) Alternate Forms
[ (left bracket) 0xad (|
] (right bracket) 0xbd |)
{ (left brace) 0x8b, 0xc0 \( or (<
} (right brace) 0x9b, 0xd0 \) or >)
| (inclusive or) 0x4f, 0x6a \!
~ (tilde) 0xa1 ¬
\ (backslash) 0xe0, 0xbe (see discussion below)

For all symbols except the backslash (), substitute sequences are not replaced in string constants or character constants. For example, the string constant "(|" contains

two characters, not a single left bracket. (Contrast this behavior with the standard trigraphs, which are replaced in string and character constants.)

The backslash is a special case because it has significance within string and character constants as well as within C statements. However, the compiler can be customized to accept an alternate single character for the backslash. In addition, the customization can include alternate single character representations of the characters in Digraph Sequences For Special Characters. The default alternate representations are listed in Default Representations for Special Characters. See your SAS Software Representative for C compiler products for more information.

Note that in addition to the digraphs described in Digraph Sequences For Special Characters, your site can customize the compiler to accept alternate single-character representations of the characters. See your site representative for details.

Special character translate table

The special character translate table enables each site to customize the representations of special characters. That is, the site decides which hexadecimal bit pattern or patterns represent that character and, thus, can choose a representation that is available on their terminals and printers. The special character translate table enables you to choose a representation of all the unusual C characters, in addition to the exclamation point (!).

The special characters that can be customized are braces ({}), square brackets ([]), not sign (¬), tilde (~), backslash (), the vertical bar (|), the exclamation point (!), and the pound sign (#). You should determine if your site has customized values for these characters and determine values. Otherwise, the default representations listed in Default Representations for Special Characters are in effect. Consult your SAS Software Representative for C compiler products for details of customized values.

Default Representations for Special Characters shows the four possible default representations for each character. The compiler and OMD (object module disassembler) accept either of two representations of the character in a source file. These are the primary and alternate representations in columns two and three. The compiler and OMD can produce either of two representations of each character in a listing file depending on the execution options specified. The first is the standard print representation shown in column four. The second, the overstrike representation listed in column five, is produced by overstriking the character with another character. (Details about the execution options and how they interact are provided in Compiler Options.) The entries in columns two through five are EBCDIC equivalents of the characters in hexadecimal notation.

Keep in mind that these alternate representations for characters apply only to C program source and not to the contents of files read by C programs.

In addition to the problem of entering C source text on devices that do not have the full character set, there is also the problem of printing the text. The compiler supports two options to assist in this area: the trans option and the upper option. See Compiler Options for more information on these options.

Note:    Do not use an underscore (_) as an overstrike character. When you specify an alternate character in the source file, the compiler places an underscore under the alternate character in the listing file. If you use an underscore as an overstrike character, it will not be clear whether the underscore in the listing file represents an alternate character or an overstrike character.  [cautionend]

Default Representations for Special Characters
Source File Representation

Listing File Representation


Character Primary Alternate Print Overstrike
left brace 0xc0

{

 0x8b

{

 0x8b

{

 0x4c / 0x4f

< with | overstrike
right brace 0xd0

}

 0x9b

}

 0x9b

}

 0x6e \ 0x4f

> with | overstrike
left bracket 0xad

[

 0xad

[

 0xad

[

 0x4c / 0x60

< with - overstrike
right bracket 0xbd 0xbd 0xbd 0x6e / 0x60

> with - overstrike
not sign (exclusive or) 0x5f 0x71 0x5f 0x5f (no overstrike)
tilde 0xa1

~

 0xa1

~

 0xa1

(degree symbol)

 0x7d / 0x60

' with - overstrike
backslash 0xe0 0xbe 0xbe 0x7e
vertical bar | or (inclusive or) 0x4f

|

 0x6a


0x4f

|

 0x4f (no overstrike)

|
pound sign 0x7b

#

 0x7b

#

 0x7b

#

 0x7b (no overstrike)

#
exclamation point 0x5a

!

 0x5a

!

 0x5a

!

 0x5a (no overstrike)

!

Escape Sequences

The compiler produces a unique char value for certain alphabetic escape sequences that represent nongraphic characters. The characters' associated hex values and ISO/ANSI meaning appear in Escape Sequence Values.

Escape Sequence Values
Sequence Hex Value Meaning
\a 0x2f alert
\b 0x16 backspace
\f 0x0c form feed
\n 0x15 new line
\r 0x0d carriage return
\t 0x05 horizontal tab
\v 0x0b vertical tab

Translation Limits

Wherever possible, the compiler avoids imposing fixed translation limits. The ISO/ANSI Standard translation limits for which the compiler does impose a fixed limit are listed in Integral Type Sizes, followed by some other limits of practical interest. If no limit is listed, the only limit is imposed by the memory available to the compiler or by the program when it is executed. The extname option can override the following translation limits for internal and external identifiers and allow 64K characters of significance:

Storage Class Limits

The total size of all objects declared in one compilation with the same storage class is limited according to the particular class, as follows:

Note that the following types of programs generate very large CSECTS:

You should consider alternatives to using large amounts of static data (for example, dynamic storage allocation via malloc ).

Storage allocated via the malloc family of routines is limited only by available memory.

Numerical Limits

The numerical limits are what you would expect for a 32-bit, two's complement machine such as the IBM 370. Integral Type Sizes shows the size ranges for the integral types.

Integral Type Sizes
Type Length in Bytes Range
char 1 0 to 255 (EBCDIC character set)
signed char 1 -128 to 127
short 2 -32768 to 32767
unsigned short 2 0 to 65535
int 4 -21474883648 to 2147483647
unsigned int 4 0 to 4294967295
long 4 -2147483648 to 2147483647
unsigned long 4 0 to 4294967295

Float and Double Type Sizes shows the size ranges for float and double types.

Float and Double Type Sizes
Type Length in Bytes Range
float 4 +/-5.4E-79 to +/-7.2E75
double 8 +/-5.4E-79 to +/-7.2E75
long double 8 +/-5.4E-79 to +/-7.2E75

For more details on the implementation of the various data types, see Code Generation Conventions.


Chapter Contents
Previous
Next
Top of Page

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