# Thoughts on unified integer literal improvements

Joseph D. Darcy Joe.Darcy at Sun.COM
Wed Jul 15 16:57:21 PDT 2009

```Weijun Wang wrote:
> Bruce Chapman wrote:
>
>> Weijun Wang wrote:
>>
>>>
>>>
>>>> Quoting Weijun Wang <Weijun.Wang at Sun.COM>:
>>>>
>>>>
>>>>
>>>>>> long ell = 0xFFFFFFFFu; // A positive long value
>>>>>>
>>>>>>
>>>>> Any particular requirement here? Why not simply
>>>>>
>>>>>  long ell = 0xFFFFFFFFl;
>>>>>
>>>>>
>>>>>
>>>>>> I think this approach has some advantages over the "y" suffix; in
>>>>>> particular I think it gives more desirable behavior in cases like
>>>>>>
>>>>>>
>>>>> this:
>>>>>
>>>>>
>>>>>> byte b = 0xFFy // a negative byte value
>>>>>> byte b = 0xFFu // also a negative byte value
>>>>>>
>>>>>> short s = 0xFFy // a negative short value, -128;
>>>>>> // byte value is signed extended
>>>>>> short s = 0xFFu // a positive short value, +127
>>>>>>
>>>>>> int i = 0xFFy // -128
>>>>>> int i = 0xFFu // 127
>>>>>>
>>>>>>
>>>>> Does this mean the actual value of 0xFFu is determined by looking at
>>>>> the
>>>>> LHS of the assignment? This is terrible.
>>>>>
>>>>>
>>>> Yes that would be terrible if it were true, fortunately it is not. The value is
>>>> determined by the digits and any radix specified by the prefix.  In the above
>>>> examples, the "y" suffix means byte, so when is widened to a short or int it
>>>> sign extends and stays negative. The "u" suffix would create a special type that
>>>> would always zero extend when widening giving a positive number.
>>>>
>>>>
>>> I still find it difficult to understand this 'u' thing. When you say
>>> "zero extend when", isn't that the same with what I said "depending on
>>> the LHS"?
>>>
>>>
>> No, The JLS defines a number of conversions, one of which is widening
>> and when that occurs. For example
>>
>> byte b = 1;
>>
>> int j = b+1;
>>
>> in the second line the type of the expression "b+1" is not determined by
>> the LHS, but the various conversion rules say that the b expression of
>> type byte must be widened to an int before the addition and assignment
>> occur in that order.
>>
>>
>> Similarly when we say
>>
>> short s = 0xFFu;
>>
>> What is happening is that the type of the expression on the right has
>> some conversions applied before the assignment. Collectively those are
>> called assignment conversion, and when 0xFFu has a type of byte, then
>> the particular assignment conversion which is applied is the widening
>> conversion.
>>
>
> I somehow understand your point. This 0xFFu is a brand new data type.
>

Not it is not; it is a more concise notation for expressing various
constants more convenient.

> Don't know if it can be coined without any new VM bytecode. Implementing
>

In two's complement arithmetic, add, subtract, and multiply give the
same bit-level results for a signed and unsigned interpretation of the
data.  For the basic operations, only a separate divide method would be
needed.  There is no need for a new bytecode to support unsigned literals.

-Joe

```