Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ncrcae.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!mcnc!ncsu!ncrcae!wescott
From: wescott@ncrcae.UUCP (Mike Wescott)
Newsgroups: net.lang.c
Subject: Re: conversion of short to unsigned it - more
Message-ID: <2131@ncrcae.UUCP>
Date: Tue, 26-Mar-85 11:50:51 EST
Article-I.D.: ncrcae.2131
Posted: Tue Mar 26 11:50:51 1985
Date-Received: Thu, 28-Mar-85 02:07:24 EST
References: <2125@ncrcae.UUCP> <7088@watdaisy.UUCP> <2128@ncrcae.UUCP> <706@turtlevax.UUCP>
Reply-To: wescott@ncrcae.UUCP (Mike Wescott)
Organization: NCR, Columbia, SC
Lines: 75
Summary: 


In my posting I complained that various C-compilers (SysVr2 and 4.2BSD)
as well as some others incorrectly generated code for

	unsigned short us;
	short s;

	if ((unsigned int)s == us) printf("OOPS\n");

The code generated for the comparison is a

	cmpw	_s, _us

No conversion. I claim s should be sign extended, us zero padded and 
a cmpl done.

Ken Turkowski @ CADLINC writes:

>I disagree.  The "(unsigned int)" is a cast, saying that s is to be
>considered unsigned rather than signed.  It is NOT a conversion.  The
>fact that s was declared to be a "short int" is immaterial; it is of
>type int rather than float, etc.  This has the same effect as saying
>"(unsigned)", without the "int".  Int has no inherent size associated
>with it; the size of an int is machine-dependent.  If you want an int
>of a specific size, you say "short int" or "long int".
>
>I would suggest that you try the statement
>
>	if ((unsigned long int)s == us) printf("OOPS\n");
>
>instead, and see if you get the same results.  This explicitly
>specifies a size conversion.

Two points:
	1. K&R (C Ref Man, sect 7.2) says that:
	   "An expression preceeded by the parenthesized name of a
	    data type causes CONVERSION of the value of the expression
	    to the names type.  This construction is called a cast."

	   A similar phrase appears in my copy of the Draft C Standard.

	 2. "if ((unsigned long int)s == us) ..." does give me the
	   same results.  The cmpw is used.


Norman Diamond of U of Waterloo, Ontario writes:

>> 	unsinged int ui;
>> 	unsigned short us;
>> 	short s;
>>
>> 	s = -3;
>> 	us = -3;
>> 	ui = s;
>>
>> 	if ((unsigned int)s == us) printf("OOPS\n");
>>
>> prints OOPS meaning that fffffffd == 0000fffd !!!
>
>It could mean 0000fffd == 0000fffd.
>If (unsigned int) s is sometimes equivalent to (unsigned int) (int) s,
>but other times equivalent to (unsigned int) (unsigned short) s,
>then I don't think any rule is being violated.  A compiler does not
>have to be consistent in its treatment of ambiguous constructs.
>(In fact, inconsistency should be encouraged because it quickens the
>discovery of bugs.)

My comments:
	1. The construction is not ambiguous as far as C Standard and
	   K&R is concerned. 
	2. Perhaps the compiler should use rand() to pick a treatment
	   of ambiguous constructs :-)

Mike Wescott
ncrcae!wescott