🚀 go-pugleaf

In article <3vtig7$9mc@louie.udel.edu>, ctaylor@stimpy.eecis.udel.edu (Clem Taylor) writes:
>In article <1995Aug3.165450.5750@sq.sq.com>, Mark Brader <msb@sq.sq.com> wrote:
>>Clem Taylor (ctaylor@stimpy.eecis.udel.edu) writes:
>>> main ( )
>>> { 
>>>     short a = 0x8000, b = 0xFFFF, c; /* signed 16 bit values */
>>
>....
>>In practice this conversion is typically done by copying the 16 low bits,
>>so that on a 2's complement machine we get -32768 for a and -1 for b,
>>but I don't believe there's anything in the standard that requires it to
>>be implemented in any particular way.  However, from here on I will assume
>>that the values *are* -32768 and -1.
>
>I think the example I gave did not completely describe hardware involved. 
>The machine in question is a 16 bit processor where 0x8000 is -32768 and
>0xFFFF is also -1. 
>
...
>
>So, on a 16 bit machine, where promotion is not an issue, is this behavior
>correct?  Does the standard specify this...

The standard specifies signed to/from unsigned integer conversion in 6.2.1.2.

Briefly, the standard states that if any such conversion can happen without
changing the value it is done so.  The case you have given (conversion from
unsigned to signed) is implementation-defined.  The behavior of your program is
therefor not guaranteed.

(Signed to unsigned conversions are however defined as one would expect with
the 2's complement representation unless narrowing is involved.)


----------------------------------------------------------------------------
 Richard Deken                   Graduate student in electrical engineering
 PGP public key available	     Tennessee Technological University
 Internet: rad6938@gemini.tntech.edu        Cookeville, TN, USA