Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/3/85; site ukma.UUCP
Path: utzoo!watmath!clyde!cbosgd!ukma!david
From: david@ukma.UUCP (David Herron, NPR Lover)
Newsgroups: net.micro,net.lang
Subject: Re: Unchecked conversion in Ada & casts in C
Message-ID: <1915@ukma.UUCP>
Date: Tue, 25-Jun-85 00:42:40 EDT
Article-I.D.: ukma.1915
Posted: Tue Jun 25 00:42:40 1985
Date-Received: Wed, 26-Jun-85 05:01:04 EDT
References: <1649@reed.UUCP> <186@harvard.ARPA> <453@calmasd.UUCP>
Reply-To: david@ukma.UUCP (David Herron, NPR Lover)
Organization: Univ. of KY Mathematical Sciences
Lines: 57
Xref: watmath net.micro:10872 net.lang:1632
Summary: Religion and the art of computer programming.

In article <74@rtp47.UUCP> throopw@rtp47.UUCP (Wayne Throop) writes:
> ...
>But here is the main point, about casts of pointers.  K&R strongly imply
>that casts of pointers deal with alignment problems.  That is, given a
>machine where (say) 16-bit integers must be instantiated in storage with
>address aligned mod 16 bits, and 8-bit characters must instantiated in
>storage with address aligned mod 8 bits, the cast "(char *) int_ptr"
>might pass the bits thru unchanged, but "(int *) char_ptr" would be free
>to align the pointer value mod 16 bits.

This is why (when I'm coding) I make extensive use of casts, etc. 
Especially when I'm the least big sure of how the types will mix.

Generally, I feel that it's the programmers duty to give the compiler
*as much* information as possible.  That is the only way the compiler
will be able to make any informed intelligent decisions about what
code to generate.  And if it still doesn't come out right then you can
point fingers at the compiler writer and shout "LAZY!".

This is certainly the way the C standard is heading.  At least in the
draft as of last October, it mainly consisted of strict definitions
of what all the operators did.  But also general enough that it wasn't
tied very closely to a PDP-11 type architecture.  (I have April's draft
but haven't looked at it yet).  But with such a definition (and compilers
that follow it) a programmer can confidently write expressions and know
that the compiler knows enough about the machine to know what conversions
he has in mind.

What's wrong with giving the compiler a lot of intelligence?  Teaching
it what all the conversions mean.  And so forth.  Then when you have
your intelligent compiler, the programmer can make use of the intelligence
to have more confidence in their code.

At least that is the ideal.

>[Another aside.  The original thread of this conversation (I think) was
> "Who needs Ada?".  Well, *I* need Ada (or *some* strongly typechecked
> language) so that I don't have to worry about stuff like pointer
> formats and what happens to them when they are abused.  I druther the
> compiler didn't let me abuse them in the first place.  That is, the
> compiler should *not let* pointers be assigned to integers, except via
> unions or explicit unchecked conversion.  But I suppose that belongs in
> net.religion.]

I prefer to describe in detail what I want to do.  But I also find assembly
language cumbersome (It takes too many lines of code to describe a simple
expression).  It's like the reason I drive a standard shift, I like having
control of my tools.
-- 
--- David Herron
--- ARPA-> ukma!david@ANL-MCS.ARPA or ukma!david<@ANL-MCS> 
---	   or david%ukma.uucp@anl-mcs.arpa
---        Or even anlams!ukma!david@ucbvax.arpa
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david

	"It's *Super*User* to the rescue!"