Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: Type checking for typedef's (new feature)
Message-ID: <2911@utcsri.UUCP>
Date: Wed, 4-Jun-86 11:41:58 EDT
Article-I.D.: utcsri.2911
Posted: Wed Jun  4 11:41:58 1986
Date-Received: Wed, 4-Jun-86 11:47:07 EDT
References: <361@batcomputer.TN.CORNELL.EDU> <138@ace.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 59
Summary: Not too terribly hard...

In article <138@ace.UUCP> henk@ace.UUCP (Henk Hesselink) writes:
>In article <361@batcomputer.TN.CORNELL.EDU> garry%cadif-oak@cu-arpa.cs.cornell.edu.arpa writes:
>
>> I am reminded of a long-standing pet peeve of mine: I can get
>> type-checking on structures and unions. I can get type-checking
>> on primitive types (int, float, ...). I CANNOT get type-checking
>> on datatypes declared via 'typedef' EXCEPT in terms of their underlying
>> types. (I assume this all is still true in the new language standard.)
>> 
>> 
>> Is it reasonable? Is it hard to implement? Comments?.
>
>It is certainly reasonable, a little more type-checking in C would not
>be at all amiss, but:
>
>"It must be emphasised that a typedef declaration does not create a
>new type in any sense" (K&R, page 141).
>
It *could* be optional.

>The problem is that typedefs get converted back to basic types fairly
>early on in pass 1 of pcc (which, plus derivatives thereof, constitutes
>a sizeable chunk of all C compilers), while serious type-checking is
>mostly done in pass 2.  This means 1) letting pcc1 keep typedefs intact,
>2) augmenting the intermediate code to allow this kind of information
>to be specified and 3) getting pcc2 to do something useful with it.

I don't think the second pass would need to know about it.
Types are stored in PCC as a string of 2-bit qualifiers preceding
a 'basic type' specifier:

	..!QUAL!QUAL!QUAL!QUAL!BASIC ( # of qualifiers depends on word size )

The qualifiers are FTN,PTR,ARY ( function returning, pointer to, array of )
and the fourth state (00) is used to 0-pad on the left. The basic types
are things like INT, UNSIGNED, STRTYPE ( i.e. struct ) ENUMTYPE ( enums ).
By adding a TYPDEF basic type, the typedef information could be retained and
checked in the first pass. The type words with TYPDEF could then be easily
converted to their actual types before writing the intermediate file. In fact
this is exactly what is done with enums, which are not seen by the second
pass and appear in the intermediate file as int constants.
The big problem is deciding *when* to issue a warning and when to
overlook mismatches.  Suppose you have 'typedef int foo;' and 'foo
i,j,k;'. then obviously i=j is ok, and so is i=j+k. But the '+' sees
two typedefs in the latter, and has to be smart enough to check them,
find out what they really are, and bump the result back to 'foo'. And
if you have 'int q', is j+q of type int or foo? do 'q +=i ' and/or
'i=j+q' give warnings? If good semantics for this could be worked out,
it could be a real aid to writing portable programs.

>Hard to implement?  Depends on where you stand, but certainly not some-
>thing you'd hack up in an afternoon.
>
True.

-- 
"We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg