«

Tim Rentsch <> writes:
> pete <> writes:
>> Tim Rentsch wrote:
>>> Keith Thompson <kst-> writes:
[...]
>>>>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.

A user-written signal handler can't have the visibility necessary to
generate a result for the conversion. I'm not convinced that an
implementation-defined signal handler can do so either, unless by
taking advantage of undefined behavior.

But (C99 7.14.1.1p3):

If and when the function [the signal handler] returns, if
the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other
implementation-defined value corresponding to a computational
exception [presumably this includes overflow on a signed integer
conversion], the behavior is undefined; otherwise the program
will resume execution at the point it was interrupted.

So if the particular undefined behavior of the implementation-defined
signal handler involves causing the conversion to yield a trap
representation, then yes, a trap representation can result from a
conversion.

It doesn't seem terribly likely, though.

--
Keith Thompson (The_Other_Keith) kst- <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"

Keith Thompson <kst-> writes:

> Tim Rentsch <> writes:
>> pete <> writes:
>>> Tim Rentsch wrote:
>>>> Keith Thompson <kst-> writes:
> [...]
>>>>>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.
>
> A user-written signal handler can't have the visibility necessary to
> generate a result for the conversion. I'm not convinced that an
> implementation-defined signal handler can do so either, unless by
> taking advantage of undefined behavior.
>
> But (C99 7.14.1.1p3):
>
> If and when the function [the signal handler] returns, if
> the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other
> implementation-defined value corresponding to a computational
> exception [presumably this includes overflow on a signed integer
> conversion], the behavior is undefined; otherwise the program
> will resume execution at the point it was interrupted.
>
> So if the particular undefined behavior of the implementation-defined
> signal handler involves causing the conversion to yield a trap
> representation, then yes, a trap representation can result from a
> conversion.

It's undefined behavior. That means the implementation is free
to define it as yielding a trap representation, and isn't even
obligated to document that decision.

> It doesn't seem terribly likely, though.

To me it does seem likely, precisely because the logic necessary
to effect a conversion is then so simple, eg, an arithmetic shift
left followed by a logical shift right. That there is no hardware
signal generated is irrelevant -- a signal raised in the abstract
machine need not have any corresponding presence in the physical
machine.

On 1/16/2010 11:52 AM, Tim Rentsch wrote:
> Eric Sosman<> writes:
>
>> On 1/16/2010 10:29 AM, Tim Rentsch wrote:
>>> "bartc"<> 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.

7.18.1.1p3: "These types are optional. However, if an
implementation provides integer types with widths of 8, 16,
32, or 64 bits, it shall define the corresponding typedef
names." That's "shall," not "may."

The implementation necessarily provides at least three
integer types that are exactly CHAR_BIT bits wide, and at
least one of those is signed. Thus if CHAR_BIT is 8, say,
the implementation must define int8_t. That type must use
two's complement representation, regardless of what is used
by `signed char'. Similarly for CHAR_BIT of 16, 32, or 64.

--
Eric Sosman
lid

Eric Sosman <> writes:

> On 1/16/2010 11:52 AM, Tim Rentsch wrote:
>> Eric Sosman<> writes:
>>
>>> On 1/16/2010 10:29 AM, Tim Rentsch wrote:
>>>> "bartc"<> 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.
>
> 7.18.1.1p3: "These types are optional. However, if an
> implementation provides integer types with widths of 8, 16,
> 32, or 64 bits, it shall define the corresponding typedef
> names." That's "shall," not "may."
>
> The implementation necessarily provides at least three
> integer types that are exactly CHAR_BIT bits wide, and at
> least one of those is signed. Thus if CHAR_BIT is 8, say,
> the implementation must define int8_t. That type must use
> two's complement representation, regardless of what is used
> by `signed char'. Similarly for CHAR_BIT of 16, 32, or 64.

I think you're referring to a pre-corrected text. I believe this
change was made as part of TC1 or TC2. Both N1124 and N1256 say
for 7.18.1.1p3:

These types are optional. However, if an implementation
provides integer types with widths of 8, 16, 32, or 64 bits, no
padding bits, and (for the signed types) that have a two's
complement representation, it shall define the corresponding
typedef names.

with a change bar by the part of the line with "padding bits", etc.

Since exact width types are required to be two's complement (per
7.18.1.1p1) the change to 7.18.1.1p3 had to be made, otherwise no
implementation with CHAR_BIT == 8 (or 16, 32, 64) could use ones'
complement or signed magnitude representations. (For that matter,
the types of those widths couldn't have padding bits either.)
Surely there was no intention to exclude such implementations. Or
do you mean to suggest that implementations having types of those
widths may use ones' complement or signed magnitude only if they
_also_ implement a set of two's complement types just for the exact
width types? It seems nutty to require such a thing.

I believe the current C99 standard allows implementations to have
CHAR_BIT == 8, 16, 32, or 64, use one's complement or signed
magnitude representation, and not define any of the exact width
integer types described in 7.18.1.1.

On 1/16/2010 4:20 PM, Tim Rentsch wrote:
> Eric Sosman<> writes:
>
>> 7.18.1.1p3: "These types are optional. However, if an
>> implementation provides integer types with widths of 8, 16,
>> 32, or 64 bits, it shall define the corresponding typedef
>> names." That's "shall," not "may."
>>
>> The implementation necessarily provides at least three
>> integer types that are exactly CHAR_BIT bits wide, and at
>> least one of those is signed. Thus if CHAR_BIT is 8, say,
>> the implementation must define int8_t. That type must use
>> two's complement representation, regardless of what is used
>> by `signed char'. Similarly for CHAR_BIT of 16, 32, or 64.
>
> I think you're referring to a pre-corrected text.

It's from ISO/IEC 9899:1999(E), the original C99. I admit
I haven't kept up with the post-2000 updates.

The real issue, though, isn't the circumstances under which
exact-width types are required, but your contention that all
integer types must use the same scheme (two's complement,
ones' complement, or signed magnitude). I brought up the exact-
width stuff as a gentle way of ridiculing the contention; can
you find any actual support for it?

--
Eric Sosman
lid

Tim Rentsch <> writes:
> Keith Thompson <kst-> writes:
[...]
>> But (C99 7.14.1.1p3):
>>
>> If and when the function [the signal handler] returns, if
>> the value of sig is SIGFPE, SIGILL, SIGSEGV, or any other
>> implementation-defined value corresponding to a computational
>> exception [presumably this includes overflow on a signed integer
>> conversion], the behavior is undefined; otherwise the program
>> will resume execution at the point it was interrupted.
>>
>> So if the particular undefined behavior of the implementation-defined
>> signal handler involves causing the conversion to yield a trap
>> representation, then yes, a trap representation can result from a
>> conversion.
>
> It's undefined behavior. That means the implementation is free
> to define it as yielding a trap representation, and isn't even
> obligated to document that decision.
>
>> It doesn't seem terribly likely, though.
>
> To me it does seem likely, precisely because the logic necessary
> to effect a conversion is then so simple, eg, an arithmetic shift
> left followed by a logical shift right. That there is no hardware
> signal generated is irrelevant -- a signal raised in the abstract
> machine need not have any corresponding presence in the physical
> machine.

The whole idea is irrelevant except on systems that actually have trap
representations for integer types; there aren't many of those around
today. In addition, the implementation would have to support C99 (C90
didn't permit the implementation-defined signal), and the implementers
would have to decide to use signal semantics to justify the chosen
behavior.

As I said, it doesn't seem terribly likely.

--
Keith Thompson (The_Other_Keith) kst- <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"

pete <> writes:
> Phil Carmody wrote:
>> So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
>> intuitive.
>
> (-0) is not a negative zero in C.

Isn't that counter-intuitive to you?

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

Joe Wright <> writes:
> Phil Carmody wrote:
>> pete <> writes:
>>> Phil Carmody wrote:
>>>> So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
>>>> intuitive.
>>> (-0) is not a negative zero in C.
>>
>> Isn't that counter-intuitive to you?
>>
>> Phil
>
> No. (-0) is counter-intuitive to me. I learned two's complement in
> 1963 and have never encountered an actual machine which used anything
> else. I also learned one's complement and signed-magnitude at the same
> time but have never seen them used in practice.

So you've never encountered any floating point numbers, then?

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

Joe Wright <> writes:
> Phil Carmody wrote:
>> Joe Wright <> writes:
>>> Phil Carmody wrote:
>>>> pete <> writes:
>>>>> Phil Carmody wrote:
>>>>>> So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
>>>>>> intuitive.
>>>>> (-0) is not a negative zero in C.
>>>> Isn't that counter-intuitive to you?
>>>>
>>>> Phil
>>> No. (-0) is counter-intuitive to me. I learned two's complement in
>>> 1963 and have never encountered an actual machine which used anything
>>> else. I also learned one's complement and signed-magnitude at the same
>>> time but have never seen them used in practice.
>>
>> So you've never encountered any floating point numbers, then?
>
> Is that supposed to be clever? You lose. In C (-0) is integral, not
> floating point. Perhaps you mean (-0.0)? Subject: plain int and signed
> int, not float.

You were talking about the methods of representation, not the
applications. The representation (having a sign bit which
represents nothing but the sign, and does not affect the
absolute value) is used in floating point units.

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

On Jan 18, 1:59*am, Phil Carmody <thefatphil_demun...@yahoo.co.uk>
wrote:
> Joe Wright <joewwri...@comcast.net> writes:
> > Phil Carmody wrote:
> >> Joe Wright <joewwri...@comcast.net> writes:
> >>> Phil Carmody wrote:
> >>>> pete <pfil...@mindspring.com> writes:
> >>>>> Phil Carmody wrote:
> >>>>>> So '-0' cannot evaluate to negative 0? Eeep, that's a bit counter-
> >>>>>> intuitive.
> >>>>> (-0) is not a negative zero in C.
> >>>> Isn't that counter-intuitive to you?
>
> >>>> Phil
> >>> No. (-0) is counter-intuitive to me. I learned two's complement in
> >>> 1963 and have never encountered an actual machine which used anything
> >>> else. I also learned one's complement and signed-magnitude at the same
> >>> time but have never seen them used in practice.
>
> >> So you've never encountered any floating point numbers, then?
>
> > Is that supposed to be clever? You lose. In C (-0) is integral, not
> > floating point. Perhaps you mean (-0.0)? Subject: plain int and signed
> > int, not float.
>
> You were talking about the methods of representation, not the
> applications. The representation (having a sign bit which
> represents nothing but the sign, and does not affect the
> absolute value) is used in floating point units.

Read again. He said he's never seen one's complement or sign-magnitude
in the real world. That has nothing to do with floating point.