home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The C Users' Group Library 1994 August
/
wc-cdrom-cusersgrouplibrary-1994-08.iso
/
vol_100
/
137_01
/
sep83col.ddj
< prev
next >
Wrap
Text File
|
1979-12-31
|
11KB
|
208 lines
.pl 60
..
.. DDJ Column #1 as of 19-Jun-83
.. (C) 1983 Anthony Skjellum.
.. For publication in DDJ
..
.. file (DDJCOL.1) created: 19-Jun-83
.. updated: 21-Jun-83
.. updated: 23-Jul-83
..
.. completed: 24-Jul-83
..
.he C/Unix Column by Anthony Skjellum. (C) 1983. For October 1983 DDJ.
This column will deal with the C programming language and the UNIX
operating system. These two software systems help programmers produce
maintainable and portable code. While C is widely supported on micro-
computers, and clearly merits discussion, UNIX is only beginning to become
available, and then only on more expensive microcomputers. Nevertheless,
UNIX design concepts are filtering down into the more conventional operat-
ing systems. This makes discussing UNIX features, successes and short-
comings both interesting and worthwhile.
This column will also include discussion of software design
approaches and current trends. Specific features of C and UNIX will be
discussed and more general programming concepts will also be presented.
This will make some of the material salient to many types of computer
systems and languages.
Readers will be invited to participate in this column. I hope that
some of the topics will spark readers into producing responses, new ideas,
and even some new code. Since this column will be bi-monthly, readers will
have plenty of time to respond to the topics covered in any given issue.
We start this first column with a discussion of the layout of C
code. The second topic is a discussion of runtime libraries and linkage
compatibility for several 8080/Z80/8086 compilers.
In the next column, we will begin to discuss how Unix-type
environments tend to produce non-interactive programs. I look forward to
your responses and suggestions for future topics.
I. Layout of C Code
The C language is one of the few standards which prevails between a
wide variety of computers. The C Programming Language, by Kernigham and
Ritchie, defines a standard language and runtime library and also discusses
implementation differences in several mini-computer implementations. The
book does not define a standard for the layout and presentation of C code,
but leaves this as a matter of personal taste. After reading a large
number of C programs from many sources, I have reached the opinion that
programmers pay too little attention to this aspect of C programming. In
the following, I will explain the problem as I see it, suggest a standard
for C code layout, and propose a possible solution.
Whenever I receive a new piece of C code, I always check to see how
the programmer has presented the code. A clear presentation with many
comments and an uncluttered look is important for maintaining such code
and for the benefit of another programmer who must understand the code.
More often than not, the code looks something like the following:
main(){printf("Hello world\n");
}
The point is that the programmer hasn't formatted his program properly.
This makes it difficult to follow the inherent block structure of the
language. The cluttered look that results from improper indentation, is
often also accompanied by a paucity of comments. The result is code which
is hard to understand, improve or debug.
The style presented in Kernigham and Ritchie is consistent, but not
optimal since it does not present blocks and block nesting in the clearest
way possible. For example, an if...else loop would look as follows:
if ((fp = fopen(argv[1],"r")) == NULL) { /* not found */
fprintf(stderr,"%s not found\n",argv[1]);
exit(1);
} else { /* the file is present */
fprintf(stderr,"%s is on-line\n",argv[1]);
fclose(fp);
}
My preference is for the following format for the above fragment:
if((fp = fopen(argv[1],"r")) == NULL) /* not found */
{
fprintf(stderr,"%s not found\n",argv[1]);
exit(1); /* exit with error status 1 */
}
else /* the file is present */
{
fprintf(stderr,"%s is on-line\n",argv[1]);
fclose(fp); /* close the file */
}
In the second form, eight-space (standard) tabs are used for indentation
(as opposed to the six-space indentation used by the book.) Braces are
almost always on their own lines and the lowest level braces appear at the
left margin. Braces indicate the nesting level of the expression which
invoked them, and their contents are themselves indented an additional
level. Only one statement is placed on a line, and comments are added
liberally to make the code more readable. Finally, the space used by
Kernigham and Ritchie between keywords and their parenthetical expressions
is omitted.
The above example illustrates the layout standard which I am
proposing. The standard is summarized in Table I. The purpose of
proposing this standard is to induce C programmers to think more carefully
about the layout and presentation of their C code. I welcome reader
reaction to this layout proposal.
Clearly, there is more to programming than just the layout of the
code. The data structures used, and program structure are crucial in
producing a good piece of software. However, without good layout, the best
program may be very difficult to understand, maintain, or improve.
A Possible Solution
I expect that even if there were a layout standard described in The
C Programming Language, some programmers would deviate from this. In order
to provide programmers with the code layouts which they prefer, C
beautifiers are created. Such programs take C code as input and add/remove
white space characters in order to reformat the C code to some layout
specification. This allows each programmer to distribute code in a
standard layout, while using the layout he prefers for local copies of the
code.
Beautifiers already exist. For example, Berkeley UNIX has a
beautifier called CB. This program is fairly simple-minded but will
convert totally unformatted C code (ie one using the minimum amount of
white space) into the Kernigham and Ritchie-type layout. More ambitious
beautifiers can be created, and this is left for readers to work on.
Readers who create their own beautifiers are invited to submit their code
for publication in this column.
We now turn to our second topic of this column: runtime libraries
and linkage compatibility in C compilers.
II. Runtime Libraries
The C Programming Language defines a standard runtime library for
C. Some of the features provided are only feasible under Unix. Thus, for
CP/M, CP/M-86, and MS-DOS implementations, only part of the runtime library
can be supported. Yet, some C compilers do not provide a compatible subset
library. The result is code which cannot be easily transported from
compiler to compiler, or machine to machine. Thus, such compilers negate
one of the primary purposes of the C programming language: portability.
The BDS C Compiler is one such software product. It is an excel-
lent subset compiler, but its runtime library is incompatible with the
standard. After using BDS C for more than three years, I have accumulated
a significant collection of useful subroutines and programs. Un-
fortunately, some of this software depends heavily on the BDS C runtime
library. This code will require significant work before it can be used
with another compiler. So be aware of this pitfall and be prepared to live
with the consequences if you choose a compiler with a non-standard runtime
library.
BDS C is not the only compiler whose runtime library is non-
standard. The Whitesmith C compilers use their own too. However, since
Whitesmith compilers are available for many different environments,
portability between Whitesmith compilers is immediate. Nevertheless, my
preference is for code written for use with the standard library and for
compilers which support that library in full or subset form.
Link Formats
Besides incompatible runtime libraries, there is the question of
subroutine linkage, and linkage editor formats. Once again BDS C is non-
standard. That is, it uses its own linker instead of conforming to the
Microsoft .REL format. (Some 8080/Z80 compilers do support the standard
such as the Q/C compiler from the Code Works). Compatibility with the .REL
format is a considerable blessing, if you plan to link other software to
your C programs.
The lack of linkage compatibility is not limited to the CP/M-80
world. A wide variety of C compilers sold for MS-DOS and CP/M-86 fail to
use the appropriate standard. Most notably, Computer Innovations' excel-
lent C86 compiler uses its own internal format. This makes it impossible
to use C86 to produce subroutines for other compiled languages under MS-DOS
or CP/M-86. Fortunately, the MANX AZTEC compilers can be used to produce
Microsoft format object code, as an option.
The reasons for the incompatibility are probably manifold. The
usual response from the companies producing the incompatible products is
that they prefer their own format to Microsoft's. Why is this? I suppose
this results from programmers who don't care about standards or just didn't
consider that their end users would find a compatible linkage format
useful. In any case, be aware of the linkage format used by the C
compilers you select.
Conclusion
In this column, we have discussed a problem in C code layout,
defined a potential layout standard and also discussed incompatibility in
C object code formats and runtime libraries.
Perhaps some interested readers will produce a C beautifier for
inclusion in this column. We look forward to your responses and
suggestions.
Next time, we'll begin discussing how Unix-type environments tend
to produce non-interactive code.