home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The C Users' Group Library 1994 August
/
wc-cdrom-cusersgrouplibrary-1994-08.iso
/
vol_100
/
137_01
/
apr84col.ddj
< prev
next >
Wrap
Text File
|
1979-12-31
|
19KB
|
484 lines
.pl 61
.po 0
..
.. this article was prepared for the C/Unix Programmer's Notebook
.. Copyright 1984 Pyramid Systems, Inc.
..
.. by A. Skjellum
..
.he "C/Unix Programmer's Notebook" for April 1984 DDJ.
Introduction
Readers responded to my December, 1983, column where I discussed
perceived deficiencies in the Unix operating system. Their comments are
included here in part.
The follow-up discussion on runtime libraries and link format
incompatibilities are also presented here.
It was also my intention to discuss two C compilers which support
the large memory concept on the 8086. One of the compilers has not yet
been received, so this comparative review will have to be included in a
future column.
I have received several more letters concerning C layout standards.
While we don't have room to include their comments at present, their
comments will undoubtedly lead to several columns concerning related topics
of interest.
Comments about Unix
In the December column, I mentioned several aspects of Unix which
I believe constitute weaknesses. Tony LiCausi of Canoga Park, California,
sent me a letter with his dissenting opinions. He begins by remarking:
"Unix was designed for the programming environment, for use by folk
already familiar with computers. Unnecessary I/O slows down a program's
performance and hence should be eliminated. Thankfully verbosity is often
eliminated, in Unix, as the default option. However many of the programs
do have command line switches to increase the progress reporting of the
program."
Unix was designed to circumvent the flaws of existing operating
systems. Under Unix, modular programs are coupled via pipelines to create a
convenient working environment and reduce repetition of effort.
Furthermore, Unix offers unequalled portability between large and small
computer systems. Since it is successful in these respects, Unix's
popularity is growing. Hence, more and more computer users are gaining
access to machines which use Unix. Many of these users are familiar with
computers and programming while others are novices to both computing and
Unix.
Let's assume that a user is well-versed in programming but is new
to Unix. According to Mr. LiCausi, this user belongs to the group of
people for whom Unix was designed. I'll assume that the user has an
application in mind, since the average user won't be writing programs as
ends unto themselves. To succeed in implementing his application, the user
will have to learn about various aspects of Unix, including various shell
commands, system calls, and runtime libraries. However, I submit that this
type of user will be slowed down significantly by overall poor quality of
the Unix documentation. Since examples in the Unix documents are typically
both terse and highly complicated, the typical user could spend an enormous
amount of time circumventing a single snag.
Imagine linking the mathematical function library as part of a C
compilation. Two seemingly possible ways for doing this are:
cc -o test test.c -lm
or
cc -lm -o test test.c
It turns out that the former method is correct while that latter produces
undefined function error messages at the linker stage. However, the
documentation does not indicate that the '-lm' must be near the end of the
line.
Our hypothetical user will also be slowed down by the cryptic
nature of error messages. It is true that the more sophisticated users
require little or no prompting, and only gentle nudges when they make an
incorrect entry, but the vast majority of users probably don't belong to
this category.
Finally, the user will be slowed down by inexplicable and un-
documented bugs in systems such as troff and eqn which I mentioned before.
Furthermore, circumventing bugs requires highly specific knowledge. Also,
the solutions, even if available, may not be widely known. On the Unix
machine I use, only a small group of people are aware of the procedure for
avoiding some common, but annoying, bugs in eqn.
Mr. LiCausi makes a very valid point concerning this:
"Software bugs are not acceptable in any form at any time. Unix
from Bell Labs is sold as unsupported software. Their attitude is, 'OK,
we'll sell it to you but, we don't want to here from you.' There is no
mechanism to report or correct bugs at the source. Source code is not
typically available to the average user. Source code is guarded on Unix
like gold; just like any other commercial software. Having done debugging
of the f77 compiler on one system, access to other software (for example
and integration) was severely limited."
Thus, while Mr. LiCausi contends that Unix was designed for people
with programming experience, he sets his standard for 'unnecessary I/O' and
'program performance' based on the most sophisticated level of Unix user.
Furthermore, it is still not clear to me why the sophisticated users should
be more willing to stand for poor quality documentation and user-unfriendly
software than every-day users. Finally, it is not at all apparent to me
from practical experience that 'many' of the standard shell commands
support extended progress reporting.
Mr. LiCausi goes on to state:
"The secret society of Unix is partially the result of the paranoia
of 'unauthorized access.' The remainder is due to the lack of commercial
incentive. The incentive has obviously increased as can be evidenced by
the proliferation of books and articles on Unix anc C."
I stated in my previous column that some users perceive Unix as a
secret society. This is the case because they cannot grasp certain aspects
of its operation based on the written and on-line documentation alone.
Only through initiated members can the knowledge (and undocumented tricks,
patches etc.) be obtained. Thus people feel left out. Other popular
operating systems do not have the same aura as Unix. For example, CP/M
users are not considered a 'secret society' even though CP/M has non-
trivial aspects. Furthermore, minicomputer operating systems such as
VAX/VMS (DEC) and AOS/VS (Data General) don't have the mysterious quality
of Unix. That's because they have much more documentation to explain the
nitty-gritty of using the system.
Mr. LiCausi finishes by stating:
"Unix is not user-unfriendly. Admittedly it is beginner hostile.
Changes will be required to adopt Unix en masse, ie for the micro, but I
hope that it does not spell the end of 'silent' software."
My final counter-remark is that most users never become sufficently
sophisticated in enough diverse aspects of Unix to escape the feeling of
user-hostility. I personally run into difficulties, even though I've used
Unix for almost four years. As soon as I use aspects of Unix which are not
part of my daily routine, 'gottchas' appear.
Other Points of View
H.T. Gordon sent in a letter concerning Unix. He writes:
"It was a pleasure to read the Skjellum critique of [Unix] in DDJ
#86. Since C/Unix is becoming the sacred cow of the computer Brahmins,
few have the courage to point out its flaws. It was designed by one of the
elite, for elite users. To them it's concise and elegant, even 'obvious.'
Only rarely is any explanation needed. If it is, a terse one will do.
Prophets inspired by the high gods cannot waste their time spelling things
out for mere morals in words of one syllable."
I don't think that the state of C/Unix is as bad as Mr. Gordon
suggests. While there are problems, I think that Unix has many strengths
and these strengths will be the basis for future operating systems. It is
the purpose of this column to discuss strengths and weaknesses of C and
Unix and to propose solutions as well as to point out the problems. I
encourage readers to pose solutions to these and other problems they
perceive.
Low level Input-Output in C
Patrick Cawood of Los Angeles writes:
"I read with great interest your last article on tendencies in Unix
to produce poor operator interaction programs. I seem to have met some of
the same in C."
"In order to provide a secure operator interface, one does not echo
a keyboard character to the screen until it has been examined and approved
by the program. But getch() function automatically echoes--even line feeds,
up arrows, etc.!! Function putch() provides an automatic line feed after
printing on the screen!!
He goes on to state:
"I simply cannot believe that anyone would wittingly design these
functions as they are, or not provide any alternative hardware interfaces.
Especially considering some of the tasks I've heard were written in C.
But perhaps these people writing serious software were all forced to write
their own hardware interfaces."
The problem which Mr. Cawood is referring to exists in a number of
non-Unix C compilers. To begin with, let's review the problem in the Unix
environment. Under Unix, putc() and getc() acquire and return a single
character respectively. However, to offload the host system, many terminal
interface boards programmatically handle user input-output in lines. Thus,
before any input is received by the host, a whole line must be entered.
Naturally, the characters are echoed by the terminal interface
hardware/firmware, and only limited line editing is permitted. On output,
a whole line is buffered up before transmission to the terminal. This
process can be overcome by use of the 'raw' terminal mode (raw implies no
host character processing.) In this mode, the program is completely
responsible for input-output. This mode is much more expensive in terms of
input-output cost, since the host must handle an interrupt for each input
character and perform an output request for each printed character.
However, as I mentioned in the previous column, this is the only way for a
program to get full control of what is entered and appears on the display
device.
With the introduction of C to microcomputers, compiler implementors
often based the behavior of the runtime libraries on their Unix experiences
rather than on The C Programming Language. Thus, whole lines are pre-
buffered by typical C runtime libraries before a single character is
received by getc(). Conversely, a whole line of output is internally
buffered before it is printed on the display. Thus, the runtime libraries
of microcomputer C compilers often emulate the terminal hardware found on
real Unix systems. However, this is not what putc() and getc() are sup-
posed to do. In the truest sense, raw mode is the fundamental terminal
mode. These functions should really work on a character by character
basis. C libraries should permit selection between the 'raw' and 'cooked'
modes (and echo, no-echo) and thus permit input-output flexibility without
resorting to assembly language routines.
One C compiler which correctly handles the low-level input-output
is the Q/C compiler from The Code Works. For example, single characters
are only required when a getchar() call is made. However, it doesn't seem
possible to turn off the echo. Nevertheless, this can be effected under
Q/C, since The Code Works is kind enough to provide runtime and compiler
source code.
Link Formats
In the October, 1983, column I discussed incompatibility between
link formats. Readers had quite a bit to say about this and their comments
are summarized here.
Guy Scharf of Mountain View, California, writes:
"I find the incompatibility of linkage editor formats to be a real
problem. For example, I want to use Digital Research's Access Manager and
Display Manager 86 with C. I would prefer CI-86 (because I am used to it)
but have to switch to DRI's C because of the link format. Another
compiler to learn and idiosynchracies to surmount."
He concludes:
"I'm not sure what to do about this problem (except complain).
David D. Clark of State College, Pennsylvania, writes:
"The big problem isn't really the format of linkable files. Even
compilers that use Microsoft's M80 and L80 will not allow linkage to code
produced by different compilers. The function calling protocols vary
tremendously from compiler to compiler. BDS C and Q/C have fairly
straightforward function calling protocols. Eco-C, on the other hand, has
a tortuous function calling sequence. And even though Q/C and Eco-C use
the Microsoft assembler and linker, the code files produced by them are not
compatible."
The problem that Mr. Clark mentions is also present in the 8086
(MS-DOS, CP/M-86) world. Code from different compilers cannot be mixed
because:
1. each requires its own main function
2. a wide variety of link formats exist
3. calling conventions differ between compilers.
The first two points are essentially insurmountable problems from the end
user's point of view. However, the third point can be overcome by adding
dummy routines to convert calling conventions.
Mr. Clark makes some additional points concerning the deficiencies
of the 8080 Microsoft .REL (relocatable) format. These are of interest
since many 8080 C compilers rely on this format. His comments are included
in Figure I. in tabular form.
------------------FIGURE I.------------------
Deficiencies in the Microsoft 8080 .REL format
and related software
1. M80 and DRI's RMAC assemblers only support six unique
characters (all upper case). This is awkward for many purposes.
2. While the .REL format apparently will handle seven unique
characters, neither M80 nor RMAC support this.
3. Apparently the .REL format, M80 and L80 were designed to work
with the FORTRAN-80 compiler which permits only six character
symbols. This is an old standard, and does not reflect the needs
of today's compilers. The absence of case sensitivity in symbols
is especially limiting.
-------------------END FIGURE I.------------------
It is obvious that an enhanced standard is necessary for the CP/M-
80 world. Even under MS-DOS, where Microsoft has enhanced the linkage
editor format, problems still exist. These problems, as I perceive them,
will be discussed next.
Microsoft's MS-DOS linkage format supports long symbols (31 unique
characters) and has case sensitivity. Thus, it overcomes the objections
that Mr. Clark posed for the 8080 .REL system. However, one nagging
problem still exists. This is the dichotomy between object modules and
libraries. Because of this dichotomy, the MS-DOS linker always includes
the full contents of a .OBJ module during linking. However, libraries are
searched. In order to make a library efficient, each function must be
compiled into its own .OBJ file. Each .OBJ file becomes a single sub-block
in the library; all the functions of that sub-block file are included at
program linkage. If libraries and object modules were equivalent, this
problem would be overcome since the functions of an object module would be
separable during linking.
Runtime Libraries
Non-standard runtime libraries are a plague to programmers. They
inhibit portability, and introduce bugs when software is transported
between different compilers. Charles Brady of New South Wales, Australia,
writes:
"An enormous contribution to standardization of C programs would be
the publication of a standard I/O library for BDS C, with, if necessary, a
modified runtime package. The very fast and efficient compiler,
particularly with the symbolic debugger tool, provides a very inviting
environment for software development. It is a great pity that this means
abundant non-standard C. As there is no inherent reason why this should be
the case ... someone should be able to ... produce a Unix compatible I/O
library."
This point is especially well-taken in view of the large amount of
BDS C software available through the C User's Group of Yates Center,
Kansas.
In the case of the runtime library itself, there is a clear
standard. This standard is spelled out in The C Programming Language. All
compilers have to do is support a proper subset appropriate to the
environment in which they work.
Conclusion
In this column, I have included the follow-up discussions on Unix
and on link formats/runtime libraries. The nature of the discussion has
been mainly of a critical nature. This is not intended to be a
condemnation of the systems, but only an impetus for readers to suggest new
ideas to improve what we already have. Unix is a worthwhile standard and
should be supported. C is a valuable tool, but can be improved. This
column is a forum in which we can discuss, develop and nurture new ideas
about C and Unix.