Intel XENIX 286 Programmers Guide (86) - Tenox.tc
Share Embed Flag
Download ePaper

Intel XENIX 286 Programmers Guide (86) - Tenox.tc

Intel XENIX 286 Programmers Guide (86) - Tenox.tc Intel XENIX 286 Programmers Guide (86) - Tenox.tc

tenox.tc
09.06.2013 Views

APPENDIX A C LANGUAGE PORTABILITY The standard definition of the C programming language leaves many details to be decided by individual implementations of the language. These unspecified features of the language detract from its portability and must be studied when attempting to write portable C code. Most of the issues affecting C portability arise from differences in either target machine hardware or compilers. C was designed to compile to efficient code for the target machine (initially a PDP-1 1), so many of the language features not precisely defined are those that reflect a particular machine's hardware characteristics. This appendix highlights the various aspects of C that may not be portable across different machines and compilers. It also briefly discusses the portability of a C program in terms of its environment, which is determined by the system calls and library routines it uses during execution, file path names it requires, and other items not guaranteed to be constant across different systems. The C language has been implemented on many different computers with widely different hardware characteristics, from small 8-bit microprocessors to large mainframes. This appendix is concerned with the portability of C code in the XENIX programming environment. This is a more restricted problem to consider since all XENIX systems to date run on hardware with the following basic characteristics: • ASCII character set • 8-bit bytes • 2-byte or 4-byte integers • Two's complement arithmetic These features are not formally defined for the language and may not be found in all implementations of C. However, the remainder of this appendix is devoted to those systems where these basic assumptions hold. The C language definition contains no specification of how input and output are performed. This is left to system calls and library routines on individual systems. Within XENIX systems there are system calls and library routines that can be considered portable. These are described briefly in a later section. This appendix is not intended as a C language primer. It is assumed that the reader is familiar with C and with the basic architecture of common microprocessors. A-1

C Language Portability XENIX Programming Program Portability A program is portable if it can be compiled and run successfully on different machines without alteration. There are many ways to write portable programs. The first is to avoid using inherently nonportable language features. The second is to isolate any nonportable interactions with the environment, such as 1/0 to nonstandard devices. For example, programs should avoid hard-coding path names unless a path name is common to all systems (e.g., /etc/passwd). Files required at compile time (i.e., include files) may also introduce nonportability if the path names are not the same on all machines. In some cases, include files containing machine parameters can be used to make the source code itself portable. Machine Hardwa re Differences in the hardware of the various target machines and differences in the corresponding C compilers cause the greatest number of portability problems. This section lists problems commonly encountered on XENIX systems. Byte Length By definition, the char data type in C must be large enough to hold as positive integers all members of a machine's character set. For the machines described in this appendix, the char size is exactly an 8-bit byte. Word Length In C, the size of the basic data types for a given implementation are not formally defined. Thus they often follow the most natural size for the underlying machine. It is safe to assume that short is no longer than long. Beyond that no assumptions are portable. For example, on some machines short is the same length as int, whereas on others long is the same length as int. Programs that need to know the size of a particular data type should avoid hard-coded constants where possible. Such information can usually be written in a fairly portable way. For example, the maximum positive integer (on a two's complement machine) can be obtained with A-2 #defi ne MAXPOS ((int) (((unsigned)-1) >> 1))

APPENDIX A<br />

C LANGUAGE PORTABILITY<br />

The standard definition of the C programming language leaves many details to be<br />

decided by individual implementations of the language. These unspecified features of<br />

the language detract from its portability and must be studied when attempting to write<br />

portable C code.<br />

Most of the issues affecting C portability arise from differences in either target<br />

machine hardware or compilers. C was designed to compile to efficient code for the<br />

target machine (initially a PDP-1 1), so many of the language features not precisely<br />

defined are those that reflect a particular machine's hardware characteristics.<br />

This appendix highlights the various aspects of C that may not be portable across<br />

different machines and compilers. It also briefly discusses the portability of a C<br />

program in terms of its environment, which is determined by the system calls and<br />

library routines it uses during execution, file path names it requires, and other items not<br />

guaranteed to be constant across different systems.<br />

The C language has been implemented on many different computers with widely<br />

different hardware characteristics, from small 8-bit microprocessors to large<br />

mainframes. This appendix is concerned with the portability of C code in the <strong>XENIX</strong><br />

programming environment. This is a more restricted problem to consider since all<br />

<strong>XENIX</strong> systems to date run on hardware with the following basic characteristics:<br />

• ASCII character set<br />

• 8-bit bytes<br />

• 2-byte or 4-byte integers<br />

• Two's complement arithmetic<br />

These features are not formally defined for the language and may not be found in all<br />

implementations of C. However, the remainder of this appendix is devoted to those<br />

systems where these basic assumptions hold.<br />

The C language definition contains no specification of how input and output are<br />

performed. This is left to system calls and library routines on individual systems. Within<br />

<strong>XENIX</strong> systems there are system calls and library routines that can be considered<br />

portable. These are described briefly in a later section.<br />

This appendix is not intended as a C language primer. It is assumed that the reader is<br />

familiar with C and with the basic architecture of common microprocessors.<br />

A-1

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!