Evaluate 16-bit signed value 0x8000 after left shift by 2

Evaluate 16-bit signed value 0x8000 after left shift by 2

[Sandeep Kumar Singh]

Hi,

I need some help/clarification,
I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2
Below is my test case.

Test case:
========
int main()
{
	register signed short val1 = 0x8000 ;
	signed short val2 ;
	val2 = ( ( val1 << 2 ) >> 2 ) ;              /* val2 should be 0. */
	printf( "\nval2 is :%x\n", val2 ) ;    /* But Val2 is ffff8000 */
	return 0 ;
}

Steps to reproduce:
$gcc   test.c
$run   a.out

I have verified the same behavior with 32-bit compilers and expected (val2=0)
with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
workaround. I want some verify my understanding for this point and another 
way to get expected result (if any).

Best Regards,
Sandeep Kumar Singh

Re: Evaluate 16-bit signed value 0x8000 after left shift by 2

[Åke Forslund]

On fre, 2014-06-13 at 06:42 +0000, Sandeep Kumar Singh wrote:
> Hi,
> 
> I need some help/clarification,
> I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2
> Below is my test case.
> 
> Test case:
> ========
> int main()
> {
> 	register signed short val1 = 0x8000 ;
> 	signed short val2 ;
> 	val2 = ( ( val1 << 2 ) >> 2 ) ;              /* val2 should be 0. */
> 	printf( "\nval2 is :%x\n", val2 ) ;    /* But Val2 is ffff8000 */
> 	return 0 ;
> }
> 
> Steps to reproduce:
> $gcc   test.c
> $run   a.out
> 
> I have verified the same behavior with 32-bit compilers and expected (val2=0)
> with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
> workaround. I want some verify my understanding for this point and another 
> way to get expected result (if any).
> 
> Best Regards,
> Sandeep Kumar Singh
> 
> 
I'm a bit rusty on how C does things but:

if I run your example and replaces %x in the printf with %hx my computer
prints "8000" which is somewhat logical since h asks printf to consider
the variable to be a short int and not a regular int.

The other thing could be that the architecture is 32 bit and the
operations are made on 32 bit words. so you'r short is represented as

	0xffff8000 in memory and then the value is shifted and left to
	0xff800000 the next right shift just moves it back
	0xffff8000

I believe the returning f could be a cpu feature that automatically adds
ones where bits would be unknown.

Regards
/Åke

Re: Evaluate 16-bit signed value 0x8000 after left shift by 2

[Andrew Haley]

On 06/13/2014 07:42 AM, Sandeep Kumar Singh wrote:

> I need some help/clarification,
> I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2

It's undefined.

ISO/IEC 9899:1999 (E)

6.5 Expressions

5  If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or
not in the range of representable values for its type), the behavior
is undefined.

> I have verified the same behavior with 32-bit compilers and expected (val2=0)
> with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
> workaround. I want some verify my understanding for this point and another 
> way to get expected result (if any).

Use an unsigned type.

6.2.5  Types

9 ... A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer
type is reduced modulo the number that is one greater than the largest
value that can be represented by the resulting type.

Andrew.

Re: Evaluate 16-bit signed value 0x8000 after left shift by 2

[Åke Forslund]

On fre, 2014-06-13 at 15:33 +0100, Andrew Haley wrote:
> On 06/13/2014 07:42 AM, Sandeep Kumar Singh wrote:
> 
> > I need some help/clarification,
> > I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2
> 
> It's undefined.
> 

A small side question is implemention defined the same as implemention
defined in this case?

> ISO/IEC 9899:1999 (E)
> 
> 6.5 Expressions
> 
> 5  If an exceptional condition occurs during the evaluation of an
> expression (that is, if the result is not mathematically defined or
> not in the range of representable values for its type), the behavior
> is undefined.
> 

> > I have verified the same behavior with 32-bit compilers and expected (val2=0)
> > with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
> > workaround. I want some verify my understanding for this point and another 
> > way to get expected result (if any).
> 
> Use an unsigned type.

> 6.2.5  Types
> 
> 9 ... A computation involving unsigned operands can never overflow, because a
> result that cannot be represented by the resulting unsigned integer
> type is reduced modulo the number that is one greater than the largest
> value that can be represented by the resulting type.
> 
> Andrew.
> 
The result is still 0x8000 and not 0 as the original author expects.

/Åke

Re: Evaluate 16-bit signed value 0x8000 after left shift by 2

[Andrew Haley]

On 06/13/2014 03:57 PM, Ã…ke Forslund wrote:
> On fre, 2014-06-13 at 15:33 +0100, Andrew Haley wrote:
>> On 06/13/2014 07:42 AM, Sandeep Kumar Singh wrote:
>>
>>> I need some help/clarification,
>>> I am expecting zero value of 16-bit signed value 0x8000 after left shift by 2
>>
>> It's undefined.
> 
> A small side question is implemention defined the same as implemention
> defined in this case?

No, it's undefined.  Anything might happen.

>> ISO/IEC 9899:1999 (E)
>>
>> 6.5 Expressions
>>
>> 5  If an exceptional condition occurs during the evaluation of an
>> expression (that is, if the result is not mathematically defined or
>> not in the range of representable values for its type), the behavior
>> is undefined.
>>
> 
>>> I have verified the same behavior with 32-bit compilers and expected (val2=0)
>>> with 16-bit compiler. I can correct this by shifting 18 in place of 2 as a
>>> workaround. I want some verify my understanding for this point and another 
>>> way to get expected result (if any).
>>
>> Use an unsigned type.
> 
>> 6.2.5  Types
>>
>> 9 ... A computation involving unsigned operands can never overflow, because a
>> result that cannot be represented by the resulting unsigned integer
>> type is reduced modulo the number that is one greater than the largest
>> value that can be represented by the resulting type.
>>
> The result is still 0x8000 and not 0 as the original author expects.

It could be 666.  Demons may fly out of your nose.

http://catb.org/jargon/html/N/nasal-demons.html

Andrew.