Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ndm20
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!convex!ndm20!tp
From: tp@ndm20
Newsgroups: net.arch
Subject: Re: char->int conversions
Message-ID: <34500001@ndm20>
Date: Sun, 20-Apr-86 09:42:00 EST
Article-I.D.: ndm20.34500001
Posted: Sun Apr 20 09:42:00 1986
Date-Received: Wed, 23-Apr-86 23:14:36 EST
References: <1423@homxb.UUCP>
Lines: 25
Nf-ID: #R:homxb.UUCP:1423:ndm20:34500001:000:1184
Nf-From: ndm20!tp    Apr 20 08:42:00 1986


>(3K bytes) were simply to clear the upper half of a register to convert
>a character to an int.  Now, the compiler *SHOULD* have been smart enough
>to recognize that the upper half already contained zero in 50-75% of
>the cases.  But it wasn't.

Consider yourself fortunate.  On the Harris H-series of machines, the
C compiler doesn't clear the top part of a char before using it as an
int if the compiler believes it to be 0.  One of  our programmers had
a mishap with a bad  pointer and  trashed the  upper part  of the int
that the char  was stored  in (this  is a  word addressable machine).
Since the compiler KNEW  that only  the bottom  byte of  the word was
set, it d idn't bother to clear the high 2 bytes (yes it is  a 24 bit
machine).  Byte operations are expensive on  this machine.   When the
char was used in  a test,  it failed  to match  a character constant.
When printed, it showed to contain exactly that character.   This was
an interesting problem to diagnose.  

Thanks,
Terry Poot
Nathan D. Maier Consulting Engineers
(214)739-4741
Usenet: {seismo!c1east | cbosgd!sun | ihnp4}!convex!infoswx!ndm20!tp
CSNET:  ndm20!tp@smu
ARPA:   ndm20!tp%smu@csnet-relay.ARPA