76
• A. R. Feuer and N. H. Gehani
strongly typed language. It is not perfect in
this regard because its strong typing can be
breached, by means of the variant record
mechanism, for example, and through rou-
tines passed as parameters. Although C is
a typed language, it is not strongly typed.
It was designed to give the programmer the
ability to manipulate data type represen-
tations. It provides several ways for viewing
the representation of an object as different
types, as in the case of unions, pointers,
parameter passing, and structure compo-
nent names.
A provision to breach strong typing is
necessary in any programming language
used for systems programming. However,
instead of including several different facili-
ties that each allow bypassing of the strong
typing mechanism, it would be better to
provide one facility especially designed for
this purpose. Then breaches of strong typ-
ing could be isolated and easily located. For
example, Ada provides the user with a ge-
netic function UNCHECKED CONVER-
SION for breaching strong typing. Unfor-
tunately, in C, typing can be breached in
several ways by means of representation
viewing.
Another difference in the type philoso-
phies of the two languages is their treat-
ment of implicit conversions. The only im-
plicit conversions allowed in PASCAL are
those that do not result in any loss of infor-
mation, as in converting from subranges to
their parent ranges and from integers to
reals (the latter is not quite correct for on
some machines not all integers can be rep-
resented as reals). For conversions between
other types, PASCAL provides type trans-
fer functions that must be called explicitly.
On the other hand, C allows implicit con-
version between any of its basic types or
pointers. The Portable C Compiler, how-
ever, does
warn
the user of implicit conver-
sions involving pointers.
PASCAL's handling of types allows me-
chanical detection of more errors than does
C's, and also prevents certain security vi-
olations, one of the most important contri-
butions of high-level languages [HORN79].
Additionally, Liskov [LISK76] advocates
that implicit conversions should almost
never be permitted even if we understand
mathematically that the conversion makes
sense, because conversions make programs
more difficult to understand. On the other
hand, PASCAL's treatment of types can
occasionally lead to problems, as in the case
of arrays. Since PASCAL considers the ar-
ray size to be part of the type of the array,
one cannot write a routine that accepts
arrays with different numbers of elements.
For example, one cannot write a routine
sort
to sort arrays of different sizes. This is
a serious handicapfi
The value of strong typing is being in-
creasingly appreciated by the C commu-
nity. Implementations of C are becoming
stricter in their treatment of types. In ad-
dition, a utility program
lint
is available
that analyzes C programs to look for viola-
tions of strong typing and other potential
sources of errors, such as using a variable
before it is initialized.
Both languages allow the user to define
new types. However, both C and PASCAL
have ignored the issue of type equivalence.
This is a detriment to program portability
since different implementations may use
different type equivalence strategies (e.g.,
name versus structural type equivalence
[WELS77]).
We conclude that PASCAL, by being
restrictive, emphasizes program reliability
and readability, while C, by its absence of
restrictions, emphasizes programmer flexi-
bility.
3. SUMMARY AND COMPARISON OF
FEATURES
This section contains a feature-by-feature
comparison of C and PASCAL. We assume
that the reader is familiar with program-
ming language concepts, but not necessarily
with either C or PASCAL. For this reason,
we describe each language feature before
discussing it. An informal syntax summary
of the languages is given in Table 1, which
presents how most of the similar facilities
in C and PASCAL are used. Items desig-
nating syntactic classes are in italics and
items surrounded by oversized square
brackets are optional. The italics conven-
tion is followed throughout the paper.
6 Solutions to ehminate this problem have been pro-
posed by Wucth [WIRT75] and others [ISO81].
Computing Surveys, Vol 14, No 1, March 1982