Velocity Reviews > plain int and signed int

# plain int and signed int

Andrew Poelstra
Guest
Posts: n/a

 01-16-2010
On 2010-01-16, Keith Thompson <(E-Mail Removed)> wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>> bartc <(E-Mail Removed)> wrote:
>>> I didn't realise a field of one bit could be signed. Seems to work though.

>>
>> Just be aware that it might only be able to hold one value, which isn't
>> very useful in most cases.

>
> I think that it could hold either 0 or -1 on a 2's-complement system.
> On a 1's-complement or sign-and-magnitude system, it could only hold
> +0 or -0.
>
> Is that what you had in mind?
>

But on a 1's complement system could you assign 0 and 1 to the field,
and differentiate between them even if they are -0 and +0?

Or could -0 be a trap representation and knock out your program?

Keith Thompson
Guest
Posts: n/a

 01-16-2010
Andrew Poelstra <(E-Mail Removed)> writes:
> On 2010-01-16, Keith Thompson <(E-Mail Removed)> wrote:
>> (E-Mail Removed) writes:
>>> bartc <(E-Mail Removed)> wrote:
>>>> I didn't realise a field of one bit could be signed. Seems to work though.
>>>
>>> Just be aware that it might only be able to hold one value, which isn't
>>> very useful in most cases.

>>
>> I think that it could hold either 0 or -1 on a 2's-complement system.
>> On a 1's-complement or sign-and-magnitude system, it could only hold
>> +0 or -0.
>>
>> Is that what you had in mind?

>
> But on a 1's complement system could you assign 0 and 1 to the field,
> and differentiate between them even if they are -0 and +0?

Not portably, I think. Converting the value 1 to the bit field's type
yields an implementation-defined value or raises an
implementation-defined signal. It's likely to do something sensible,
but there are no guarantees.

I can't think of a good reason to use a 1-bit signed bit field, even
if its behavior were well-defined.

> Or could -0 be a trap representation and knock out your program?

I think -0 can be a trap representation, but if it is it can't be the
result of a conversion of a valid value.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Tim Rentsch
Guest
Posts: n/a

 01-16-2010
Keith Thompson <(E-Mail Removed)> writes:

> (E-Mail Removed) writes:
>> bartc <(E-Mail Removed)> wrote:
>>> I didn't realise a field of one bit could be signed. Seems to work though.

>>
>> Just be aware that it might only be able to hold one value, which isn't
>> very useful in most cases.

>
> I think that it could hold either 0 or -1 on a 2's-complement system.
> On a 1's-complement or sign-and-magnitude system, it could only hold
> +0 or -0.
>
> Is that what you had in mind?

Or, in all three cases (s/m, 1's complement, 2's complement), the
representation different from +0 could be a trap representation.

Tim Rentsch
Guest
Posts: n/a

 01-16-2010
Keith Thompson <(E-Mail Removed)> writes:

> Andrew Poelstra <(E-Mail Removed)> writes:
>> On 2010-01-16, Keith Thompson <(E-Mail Removed)> wrote:
>>> (E-Mail Removed) writes:
>>>> bartc <(E-Mail Removed)> wrote:
>>>>> I didn't realise a field of one bit could be signed. Seems to work though.
>>>>
>>>> Just be aware that it might only be able to hold one value, which isn't
>>>> very useful in most cases.
>>>
>>> I think that it could hold either 0 or -1 on a 2's-complement system.
>>> On a 1's-complement or sign-and-magnitude system, it could only hold
>>> +0 or -0.
>>>
>>> Is that what you had in mind?

>>
>> But on a 1's complement system could you assign 0 and 1 to the field,
>> and differentiate between them even if they are -0 and +0?

>
> Not portably, I think. Converting the value 1 to the bit field's type
> yields an implementation-defined value or raises an
> implementation-defined signal. It's likely to do something sensible,
> but there are no guarantees.
>
> I can't think of a good reason to use a 1-bit signed bit field, even
> if its behavior were well-defined.
>
>> Or could -0 be a trap representation and knock out your program?

>
> I think -0 can be a trap representation, but if it is it can't be the
> result of a conversion of a valid value.

Of course it can. The implementation-defined signal produced
by the out-of-range conversion can produce whatever representation
it wants to.

bartc
Guest
Posts: n/a

 01-16-2010

"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (E-Mail Removed) writes:
>> bartc <(E-Mail Removed)> wrote:
>>> I didn't realise a field of one bit could be signed. Seems to work
>>> though.

>>
>> Just be aware that it might only be able to hold one value, which isn't
>> very useful in most cases.

>
> I think that it could hold either 0 or -1 on a 2's-complement system.
> On a 1's-complement or sign-and-magnitude system, it could only hold
> +0 or -0.

Would a bitfield necessarily have to use the same integer representation as
ordinary integer values?

--
Bartc

Tim Rentsch
Guest
Posts: n/a

 01-16-2010
pete <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>>
>>
>>>Andrew Poelstra <(E-Mail Removed)> writes:
>>>
>>>>On 2010-01-16, Keith Thompson <(E-Mail Removed)> wrote:
>>>>
>>>>>(E-Mail Removed) writes:
>>>>>
>>>>>>bartc <(E-Mail Removed)> wrote:
>>>>>>
>>>>>>>I didn't realise a field of one bit could be signed. Seems to work though.
>>>>>>
>>>>>>Just be aware that it might only be able to hold one value, which isn't
>>>>>>very useful in most cases.
>>>>>
>>>>>I think that it could hold either 0 or -1 on a 2's-complement system.
>>>>>On a 1's-complement or sign-and-magnitude system, it could only hold
>>>>>+0 or -0.
>>>>>
>>>>>Is that what you had in mind?
>>>>
>>>>But on a 1's complement system could you assign 0 and 1 to the field,
>>>>and differentiate between them even if they are -0 and +0?
>>>
>>>Not portably, I think. Converting the value 1 to the bit field's type
>>>yields an implementation-defined value or raises an
>>>implementation-defined signal. It's likely to do something sensible,
>>>but there are no guarantees.
>>>
>>>I can't think of a good reason to use a 1-bit signed bit field, even
>>>if its behavior were well-defined.
>>>
>>>
>>>>Or could -0 be a trap representation and knock out your program?
>>>
>>>I think -0 can be a trap representation, but if it is it can't be the
>>>result of a conversion of a valid value.

>>
>>
>> Of course it can. The implementation-defined signal produced
>> by the out-of-range conversion can produce whatever representation
>> it wants to.

>
> INTERNATIONAL STANDARD
> ISO/IEC 9899
>
> 6.2.6.2 Integer types
>
> 3 If the implementation supports negative zeros,
> they shall be generated only by:
> * the &, |, ^, ~, <<, and >> operators with arguments that
> produce such a value;
> * the +, -, *, /, and % operators where one argument is a
> negative zero and the result is zero;
> * compound assignment operators based on the above cases.

Right, but an out-of-range value is being converted:

6.3.1.3 Signed and unsigned integers

3 Otherwise, the new type is signed and the value cannot be
represented in it; either the result is implementation-defined
or an implementation-defined signal is raised.

The implementation-supplied signal handler for this signal is
free to use &, |, etc, to generate a result for the conversion.
Remember the semantics of default signal handlers are
implementation-defined.

Tim Rentsch
Guest
Posts: n/a

 01-16-2010
"bartc" <(E-Mail Removed)> writes:

> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> (E-Mail Removed) writes:
>>> bartc <(E-Mail Removed)> wrote:
>>>> I didn't realise a field of one bit could be signed. Seems to work
>>>> though.
>>>
>>> Just be aware that it might only be able to hold one value, which isn't
>>> very useful in most cases.

>>
>> I think that it could hold either 0 or -1 on a 2's-complement system.
>> On a 1's-complement or sign-and-magnitude system, it could only hold
>> +0 or -0.

>
> Would a bitfield necessarily have to use the same integer
> representation as ordinary integer values?

Debatable. My reading is that all integer types have to follow
the same basic choices (2's complement vs 1's complement vs s/m,
whether or not the distinguished value is a trap representation)
in how signed types (including signed bitfields) are represented,
but I don't know if there's any sort of consensus on the
question.

Eric Sosman
Guest
Posts: n/a

 01-16-2010
On 1/16/2010 10:29 AM, Tim Rentsch wrote:
> "bartc"<(E-Mail Removed)> writes:
>>
>> Would a bitfield necessarily have to use the same integer
>> representation as ordinary integer values?

>
> Debatable. My reading is that all integer types have to follow
> the same basic choices (2's complement vs 1's complement vs s/m,
> whether or not the distinguished value is a trap representation)
> in how signed types (including signed bitfields) are represented,
> but I don't know if there's any sort of consensus on the
> question.

7.18.1.1 requires that exact-width signed integer types
(if they exist) must use two's complement representation.
Therefore, if all signed integer types must follow the same
scheme for representing negative values, either

1) Ones' complement and signed magnitude representations
are forbidden, or

2) There are no exact-width integer types.

Note that (2) implies CHAR_BIT is not 8, 16, 32, or 64.

--
Eric Sosman
(E-Mail Removed)lid

Phil Carmody
Guest
Posts: n/a

 01-16-2010
pete <(E-Mail Removed)> writes:
> Tim Rentsch wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>>>Andrew Poelstra <(E-Mail Removed)> writes:
>>>>On 2010-01-16, Keith Thompson <(E-Mail Removed)> wrote:
>>>>>(E-Mail Removed) writes:
>>>>>>bartc <(E-Mail Removed)> wrote:
>>>>>>>I didn't realise a field of one bit could be signed.

....
>>>I think -0 can be a trap representation, but if it is it can't be the
>>>result of a conversion of a valid value.

>>
>> Of course it can. The implementation-defined signal produced
>> by the out-of-range conversion can produce whatever representation
>> it wants to.

>
> INTERNATIONAL STANDARD
> ISO/IEC 9899
>
> 6.2.6.2 Integer types
>
> 3 If the implementation supports negative zeros,
> they shall be generated only by:
> . the &, |, ^, ~, <<, and >> operators with arguments that
> produce such a value;
> . the +, -, *, /, and % operators where one argument is a
> negative zero and the result is zero;
> . compound assignment operators based on the above cases.

So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
intuitive.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

Tim Rentsch
Guest
Posts: n/a

 01-16-2010
Eric Sosman <(E-Mail Removed)> writes:

> On 1/16/2010 10:29 AM, Tim Rentsch wrote:
>> "bartc"<(E-Mail Removed)> writes:
>>>
>>> Would a bitfield necessarily have to use the same integer
>>> representation as ordinary integer values?

>>
>> Debatable. My reading is that all integer types have to follow
>> the same basic choices (2's complement vs 1's complement vs s/m,
>> whether or not the distinguished value is a trap representation)
>> in how signed types (including signed bitfields) are represented,
>> but I don't know if there's any sort of consensus on the
>> question.

Clarification: all integer types _in any particular implmentation_.
Obviously different implementations can make different choices.

> 7.18.1.1 requires that exact-width signed integer types
> (if they exist) must use two's complement representation.
> Therefore, if all signed integer types must follow the same
> scheme for representing negative values, either
>
> 1) Ones' complement and signed magnitude representations
> are forbidden, or
>
> 2) There are no exact-width integer types.

In fact I think that's right -- an implementation can have exact-width
integer types, or use a { 1's complement, s/m } representation, but
not both.

> Note that (2) implies CHAR_BIT is not 8, 16, 32, or 64.

No, an implementation can have CHAR_BIT be any of those values but
use a representation other than 2's complement, in which case it
won't have exact-width integer types. N1256 is explicit that
having a 2's complement representation is a pre-requisite for
requiring the exact width types be defined.