Intel XENIX 286 Programmers Guide (86) - Tenox.tc
Intel XENIX 286 Programmers Guide (86) - Tenox.tc Intel XENIX 286 Programmers Guide (86) - Tenox.tc
XENIX Programming C Language Portability Side Effects, Evaluation Order The C language makes few guarantees about the order of evaluation of operands in an expression or arguments to a function call. Thus func(i + +, i + + ) ; is extremely nonportable, and even func(i + + ); is unwise if func is ever likely to be replaced by a macro, since the macro may use i more than once. Certain XENIX macros are commonly used in user programs; these are all guaranteed to use their argument once, and so can safely be called with a sideeffect argument. The most common examples are getc, putc, getchar, and putchar. Operands to the following operators are guaranteed to be evaluated left to right: && II ? Note that the comma operator above is a separator for C expressions. (For example, the expression (a, b, c, d) evaluates a, then b, then c, and last d, returning the value of d as the value of the entire expression.) A list of items separated by commas in a declaration list is not guaranteed to be processed left to right. Thus the declaration register int a, b, c, d; on a PDP-11 where only three register variables may be declared could make any three of the four variables register type, depending on the compiler. The correct declaration is to decide the order of importance of the variables being register type, and then use separate declaration statements, since the order of processing of individual declaration statements is guaranteed to be sequential: register int a; register int b· I register int c; register int d; Program Environment Differences Most programs make system calls and use library routines for various services. This section indicates some of those routines that are not always portable, and those that particularly aid portability. We are concerned here primarily with portability under the XENIX operating system. Many of the XENIX system calls are specific to that particular operating system environment and are not present on all other operating system implementations of C. Examples of this are getpwent for accessing entries in the XENIX password file, and getenv, which is specific to the XENIX concept of a process's environment. A-ll
C Language Portability XENIX Programming Any program containing hard-coded path names to files or directories, or user IDs, login names, terminal lines, or other system dependent parameters is nonportable. These types of constants should be in header files, passed as command line argu ments, obtained from the environment, or obtained by using the XENIX default parameter library routines defopen and defread. Within XENIX, most system calls and library routines are portable across different implementations and XENIX releases. However, a few routines have changed in their user interface. The XENIX library routines are usually portable among XENIX systems. Note that the members of the printf and scanf families, printf, fprintf, scanf, fscanf, and sscanf have changed in several ways during the evolution of XENIX, and some features are not completely portable. The return values of these routines cannot be relied on to have the same meaning on all systems. Some of the format conversion characters have changed their meanings, in particular those relating to uppercase and lowercase in the output of hexadecimal numbers, and the specification of long integers on 16-bit word machines. Portability of Data Data files are almost always nonportable across different machine CPU architectures. As mentioned above, structures, unions, and arrays have varying internal layout and padding requirements on different machines. In addition, byte ordering within words and actual word length may differ. The only way to achieve data file portability is to write and read data files as onedimensional character arrays. This avoids align ment and padding problems if the data is written and read as characters and interpreted that way. Thus ASCII text files can usually be moved between different machine types without too many problems. lint lint is a C program checker that attempts to detect features of a collection of C source files that are nonportable or even incorrect C. One particular advantage of lint over any compiler checking is that lint checks function declaration and usage across source files. Neither compiler nor loader do this. lint will generate warning messages about nonportable pointer arithmetic, assignments, and type conversions. However, being passed by lint is not a guarantee that a program is completely portable. A-12
- Page 212 and 213: XENIX Programming yacc: Compiler-Co
- Page 214 and 215: XENIX Programming yacc: Compiler-Co
- Page 216 and 217: XENIX Programming yacc: Compiler-Co
- Page 218 and 219: XENIX Programming yacc: Compiler-Co
- Page 220 and 221: XENIX Programming yacc: Compiler-Co
- Page 222 and 223: XENIX Programming yacc: Compiler-Co
- Page 224 and 225: XENIX Programming yacc: Compiler-Co
- Page 226 and 227: XENIX Programming yacc: Compiler-Co
- Page 228 and 229: XENIX Programming yacc: Compiler-Co
- Page 230 and 231: XENIX Programming yacc: Compiler-Co
- Page 232 and 233: XENIX Programming yacc: Compiler-Co
- Page 234 and 235: XENIX Programming yacc: Compiler-Co
- Page 236 and 237: XENIX Programming %left %left %left
- Page 238 and 239: XENIX Programming I* lexical analys
- Page 240: XENIX Programming yacc: Compiler-Co
- Page 243 and 244: m4: Macro Processor XENIX Programmi
- Page 245 and 246: m4: Macro Processor XENIX Programmi
- Page 247 and 248: m4: Macro Processor XENIX Programm
- Page 249 and 250: m4: Macro Processor XENIX Programmi
- Page 251 and 252: m4: Macro Processor XENIX Programmi
- Page 253 and 254: C Language Portability XENIX Progra
- Page 255 and 256: C Language Portability XENIX Progra
- Page 257 and 258: C Language Portability XENIX Progra
- Page 259 and 260: C Language Portability XENIX Progra
- Page 261: C Language Portability XENIX Progra
- Page 266 and 267: APPENDIX B PROG RAMMING COMMANDS Th
- Page 268 and 269: XENIX Programming ad b (continued)
- Page 270 and 271: XENIX Programming Programming Comma
- Page 272 and 273: XENIX Programming Programming Comma
- Page 274 and 275: XENIX Programming Programming Comma
- Page 276 and 277: XENIX Programming Programming Comma
- Page 278 and 279: XENIX Programming Programming Comma
- Page 280 and 281: XENIX Programming Programming Comma
- Page 282 and 283: XENIX Programming Programming Comma
- Page 284 and 285: XENIX Programming as (continued) Fi
- Page 286 and 287: XENIX Programming Programming Comma
- Page 288 and 289: XENIX Programming Programming Comma
- Page 290 and 291: XENIX Programming Programm ing Comm
- Page 292 and 293: XENIX Programming Programming Comma
- Page 294 and 295: XENIX Programming Programming Comma
- Page 296 and 297: XENIX Programming Programm ing Comm
- Page 298 and 299: XENIX Programming Programming Comma
- Page 300 and 301: XENIX Programming Programming Comma
- Page 302 and 303: XENIX Programming Programming Comma
- Page 304 and 305: XENIX Programming Programming Comma
- Page 306 and 307: XENIX Programming Programming Comma
- Page 308 and 309: XENIX Programming Programming Comma
- Page 310 and 311: XENIX Programming Programming Comma
C Language Portability <strong>XENIX</strong> Programming<br />
Any program containing hard-coded path names to files or directories, or user IDs, login<br />
names, terminal lines, or other system dependent parameters is nonportable. These<br />
types of constants should be in header files, passed as command line argu ments,<br />
obtained from the environment, or obtained by using the <strong>XENIX</strong> default parameter<br />
library routines defopen and defread.<br />
Within <strong>XENIX</strong>, most system calls and library routines are portable across different<br />
implementations and <strong>XENIX</strong> releases. However, a few routines have changed in their<br />
user interface. The <strong>XENIX</strong> library routines are usually portable among <strong>XENIX</strong> systems.<br />
Note that the members of the printf and scanf families, printf, fprintf, scanf, fscanf,<br />
and sscanf have changed in several ways during the evolution of <strong>XENIX</strong>, and some<br />
features are not completely portable. The return values of these routines cannot be<br />
relied on to have the same meaning on all systems. Some of the format conversion<br />
characters have changed their meanings, in particular those relating to uppercase and<br />
lowercase in the output of hexadecimal numbers, and the specification of long integers<br />
on 16-bit word machines.<br />
Portability of Data<br />
Data files are almost always nonportable across different machine CPU architectures.<br />
As mentioned above, structures, unions, and arrays have varying internal layout and<br />
padding requirements on different machines. In addition, byte ordering within words and<br />
actual word length may differ.<br />
The only way to achieve data file portability is to write and read data files as onedimensional<br />
character arrays. This avoids align ment and padding problems if the data is<br />
written and read as characters and interpreted that way. Thus ASCII text files can<br />
usually be moved between different machine types without too many problems.<br />
lint<br />
lint is a C program checker that attempts to detect features of a collection of C source<br />
files that are nonportable or even incorrect C. One particular advantage of lint over<br />
any compiler checking is that lint checks function declaration and usage across source<br />
files. Neither compiler nor loader do this.<br />
lint will generate warning messages about nonportable pointer arithmetic, assignments,<br />
and type conversions. However, being passed by lint is not a guarantee that a program<br />
is completely portable.<br />
A-12