Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: C strongly typed?
Message-ID: <23015@mimsy.umd.edu>
Date: 10 Mar 90 06:23:01 GMT
References: <259@eiffel.UUCP> <1990Mar1.172526.28683@utzoo.uucp> <849@enea.se> <25F85CF6.7304@paris.ics.uci.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 101

>>... C doesn't have a `char' type in the same sense as Pascal, et. al.

In article <25F85CF6.7304@paris.ics.uci.edu> bvickers@ics.uci.edu
(Brett J. Vickers) writes:
>In other words, C is NOT strongly typed.

No.  In other words, C does not have a character type.  Or, put another
way, C has several integer types, but no character type.  You cannot make
from this the conclusion `C is not strongly typed.'

>The very fact that C treats characters as 8-bit integers suggests this.
>It is fundamentally flexible where type is concerned.

C's type compatibility scheme opts for flexibility, yes.  But this does
not warrant your conclusion (`C not strongly typed') without a very strange
definition of `strongly typed'.

C has these types:

		     { made	integer:  char, short, int, long
	arithmetic   { up
		     { from	floating: float, double

		(plus unsigned variants and extensions such as `long long')

	pointer			(points to some other type)

		     { made	array (of some other type)
	aggregate    { up	struct (containing one or more elements)
		     { from	union (an undiscriminated union)

	function		(returns some other type)

	void			(has no value)

	enumerated		(rather peculiar; see comp.std.c for
				 discussion of ANSI C enumerated types
				 and constants.)

None of these basic types are assignment compatible.  Some of them
cannot even be named outside a cast or declaration (namely array types
and function types; no expression values have such a type).  In
addition, each distinct pointer, structure, array, union, or function
type is not assignment compatible with any other type unless it is in
some fundamental way `the same'.  (Enumerated types may be assignment
compatible, depending on your compiler.)  For instance, given

	char **cpp;
	int *ip;
	char **z;
	short *(*fp)(char *);
	short *(*fp2)(int);

`z' and `cpp' are assignment compatible, because they are both pointers
that point to identical types.  Neither is assignment compatible with ip
or fp, even though both ip and fp are also pointers.  A compiler that
does not produce a diagnostic for

	z = fp;

does not conform to the ANSI standard.  Furthermore, fp and fp2 are not
type compatible, and again a compiler that does not produce a diagnostic
does not conform to the standard, even though they differ only in argument
types.

What does confuse many people is that the arithmetic types are all
assignment-compatible.  This leads them to conclude that C is not
strongly typed.  Were that the case, I, for one, would not expect

	int i = 1;
	float f;

	f = i;

to put `1.0' into f, but rather to act as if I had written

	*(int *)&f = i;

or

	f = *(float *)&i;

so that `f' would become, e.g., 1.4013e-45 (using IEEE float,
little-endian int, on a DECstation).  But f becomes 1.0.  The type
system has intervened, changing the bit pattern in passing.  The same
*does* happen for

	char c; int i; c = i;

but the conversion is less well defined.  If the value in `i' is out of
range for a `char' variable---that range being CHAR_MIN..CHAR_MAX---the
result is undefined, much as the result of

	var r: real; i: integer;
	... i := trunc(r); ...

is (probably; I do not have any Pascal standard around to check) undefined
when `r' is not in the range of `i'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris