plain int and signed int
happy
unsigned in a particular implementaion,
Can signed int and plain int be different or are they guaranteed to be
same?
Nick Keighley
an int is a signed int
Richard Heathfield
unless it's a bit-field, in which case you'd better specify which one
you want, signed or unsigned. Otherwise the implementation gets to choose.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Keith Thompson
Plain char and signed char are always distinct types. They may or
may not have the same representation.
"signed int" and "int" are simply two different names for the same
type, with one exception: the name "int", when it's the type of a bit
field, may refer either to signed int or to unsigned int. (Thanks to
Richard Heathfield for pointing that out; I would have forgotten it.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
happy
> happy <hppymit...@yahoo.com> writes:
> > As signed char and plain char can be different if plain char is
> > unsigned in a particular implementaion,
> > Can signed int and plain int be different or are they guaranteed to be
> > same?
>
> Plain char and signed char are always distinct types. They may or
> may not have the same representation.
>
distinct ?
I mean can they have different representations?
Ben Pfaff
> Even if plain char is signed, then also are plain and signed char
> distinct ?
> I mean can they have different representations?
If plain char is signed, then plain char and signed char have the
same representation.
If plain char is unsigned, then plain char and unsigned char have
the same representation.
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_
Eric Sosman
Signed char is a type. Unsigned char is another type,
whose representation is necessarily different from that of
signed char.
Plain char is a third type. It has the same representation
as one of the first two -- either signed char or unsigned char --
but is a distinct type nonetheless.
Many people find this weird, for a simple reason: It's weird.
But that's the way it is, mostly for historical reasons.
If it's any comfort, consider that on many systems there are
only two representations shared among the three distinct types
short, int, and long: Usually short and long are different, and
int has the same representation as one or the other. But short
and int are distinct types even on systems where they have the
same representation, while int and long are distinct even on
systems where *they* have the same representation.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Keith Thompson
Yes.
> I mean can they have different representations?
No.
If plain char is signed, then plain char and signed char are two
disinct types with exactly the same range and representation.
Some examples:
char c = 'c';
signed char s = 's';
/* The actual values are not important */
c = s; /* ok, involves an implicit type conversion */
s = c; /* ok, as above */
/* Note that the implicit type conversions above don't do
any actual work.
*/
char *pc = &c;
signed char *ps = &s;
pc = ps; /* constraint violation, requires a diagnostic */
ps = pc; /* constraint violation, requires a diagnostic */
Since C permits implicit conversions between any two arithmetic
types, the fact that two such types are distinct *usually* isn't very
important. But pointers to two such distinct types are themselves
distinct pointer types, and there are no implicit conversions for
distinct pointer types (other than void* and some special cases
for null pointer constants)
bartc
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:BKSdnYKgzefYYdPW...@bt.com...
> Nick Keighley wrote:
>> On 14 Jan, 09:03, happy <hppymit...@yahoo.com> wrote:
>>
>>> As signed char and plain char can be different if plain char is
>>> unsigned in a particular implementaion,
>>> Can signed int and plain int be different or are they guaranteed to be
>>> same?
>>
>> an int is a signed int
>
> unless it's a bit-field, in which case you'd better specify which one you
> want, signed or unsigned. Otherwise the implementation gets to choose.
I didn't realise a field of one bit could be signed. Seems to work though.
--
Bartc
lawrenc...@siemens.com
>
> 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.
--
Larry Jones
I don't think that question was very hypothetical at all. -- Calvin
Keith Thompson
> bartc <ba...@freeuk.com> 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?
Andrew Poelstra
> lawrenc...@siemens.com writes:
>> bartc <ba...@freeuk.com> 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
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.
Tim Rentsch
> lawrenc...@siemens.com writes:
>> bartc <ba...@freeuk.com> 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
> Andrew Poelstra <apoe...@localhost.localdomain> writes:
>> On 2010-01-16, Keith Thompson <ks...@mib.org> wrote:
>>> lawrenc...@siemens.com writes:
>>>> bartc <ba...@freeuk.com> 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.
pete
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.
--
pete
bartc
"Keith Thompson" <ks...@mib.org> wrote in message
news:ln3a26d...@nuthaus.mib.org...
> lawrenc...@siemens.com writes:
>> bartc <ba...@freeuk.com> 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
> * 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
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
> "bartc"<ba...@freeuk.com> 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
eso...@ieee-dot-org.invalid
Phil Carmody
> Tim Rentsch wrote:
>> Keith Thompson <ks...@mib.org> writes:
>>>Andrew Poelstra <apoe...@localhost.localdomain> writes:
>>>>On 2010-01-16, Keith Thompson <ks...@mib.org> wrote:
>>>>>lawrenc...@siemens.com writes:
>>>>>>bartc <ba...@freeuk.com> 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:
> produce such a value;
> . the +, -, *, /, and % operators where one argument is a
> negative zero and the result is zero;
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
> On 1/16/2010 10:29 AM, Tim Rentsch wrote:
>> "bartc"<ba...@freeuk.com> 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.
Keith Thompson
> pete <pfi...@mindspring.com> writes:
>> Tim Rentsch wrote:
>>> Keith Thompson <ks...@mib.org> 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.
Tim Rentsch
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.
Eric Sosman
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
eso...@ieee-dot-org.invalid
Tim Rentsch
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.
Eric Sosman
> Eric Sosman<eso...@ieee-dot-org.invalid> 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
eso...@ieee-dot-org.invalid
Keith Thompson
>>
>> 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.
pete
(-0) is not a negative zero in C.
--
pete
Phil Carmody
> 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?
Joe Wright
> pete <pfi...@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.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Phil Carmody
> Phil Carmody wrote:
>> pete <pfi...@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?
Joe Wright
> Joe Wright <joeww...@comcast.net> writes:
>> Phil Carmody wrote:
>>> pete <pfi...@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?
>
> Phil
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.
Phil Carmody
> Phil Carmody wrote:
>> Joe Wright <joeww...@comcast.net> writes:
>>> Phil Carmody wrote:
>>>> pete <pfi...@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?
>
> 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.
Squeamizh
wrote:
> >>>>> 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.
Peter Nilsson
> Phil Carmody <thefatphil_demun...@yahoo.co.uk> wrote:
> > Joe Wright <joewwri...@comcast.net> writes:
> > > Phil Carmody wrote:
> > >> Joe Wright <joewwri...@comcast.net> writes:
> > >>> 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.
I do recall someone mentioning (or theorising) about a machine
that only had a floating point unit that implemented integers
using a non-normalised representation. The exponent would simply
be padding bits. (...and UINT_MAX would equal INT_MAX.)
> > 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.
Neither of you can recognise, let alone acknowledge, the
similarity between sign-mantissa and exponent-sign-mantissa?
If Joe's ever written -1 on a piece of paper, then he has
seen sign-magnitude in the real world, even if he's never
seen it implemented for integers on a cpu.
But from what I read, people are still designing the odd DSP
chip to use sign-magnitude integers.
--
Peter
Joe Wright
> If Joe's ever written -1 on a piece of paper, then he has
> seen sign-magnitude in the real world, even if he's never
> seen it implemented for integers on a cpu.
>
Silly.
> But from what I read, people are still designing the odd DSP
> chip to use sign-magnitude integers.
>
Really? I am not familiar with DSP's at all. But I am curious. Why would a
chip designer, knowing all three, choose sign-magnitude or one's complement
over two's complement for fundamental integer math?
> --
> Peter
Squeamizh
This might come as a shock to you (please brace yourself) - a CPU does
not contain a little man with a pencil and paper.
Eric Sosman
> [...]
> I do recall someone mentioning (or theorising) about a machine
> that only had a floating point unit that implemented integers
> using a non-normalised representation. The exponent would simply
> be padding bits. (...and UINT_MAX would equal INT_MAX.)
IIRC[*] it was a Burroughs machine of 1960's vintage.
You could pass integers and floating-point values around
interchangeably; words with all-zero exponent fields were
integers, others were F-P.
I don't recall further details of the representations,
nor whether there was a distinction between signed and
unsigned arithmetic. This was all pre-C, in any case; the
thing that caught my eye was that in this machine's FORTRAN
it was not an error to pass an integer value to a subroutine
expecting F-P, or vice versa.
[*] By no means a sure bet. I recall reading about the
machine, but I never actually used or wrote programs for it.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Tim Rentsch
The language in 6.2.6.2p2, talking about signed integer types,
clearly is talking about the signed integer types as a group.
Notice the last subparagraph (the one that starts "Which of these
applies is implementation-defined..."). ISTM that there is less
strain in the writing if this is interpreted as applying to all
signed integer types as a group rather than as a separate decision
for each individual type. Certainly it would have been easy to
say "... is implementation-defined for each type ..." if that had
been the intention. But the text doesn't say that.
Also, notice the wording in 6.2.6.2p3 and p4. "If the implementation
supports negative zeros ..." and "If the implementation does not
support negative zeros ...". Pretty clearly this wording reflects an
expectation that supporting or not supporting negative zeros is an
implementation-wide decision, not a per-type decision. But negative
zeros are first discussed in that same last subparagraph of 6.2.6.2p2
just mentioned. It doesn't make sense that negative zeros should be
an implementation-wide decision but the choice of 2's complement, 1's
complement, or s/m, should be a per-type decision.
Phil Carmody
The real world has nothing to do with floating point?
Woh - you've never worked as a DSP programmer.
PHil
Phil Carmody
> On 1/18/2010 9:28 PM, Peter Nilsson wrote:
>> [...]
>> I do recall someone mentioning (or theorising) about a machine
>> that only had a floating point unit that implemented integers
>> using a non-normalised representation. The exponent would simply
>> be padding bits. (...and UINT_MAX would equal INT_MAX.)
>
> IIRC[*] it was a Burroughs machine of 1960's vintage.
> You could pass integers and floating-point values around
> interchangeably; words with all-zero exponent fields were
> integers, others were F-P.
Not just the 60s. In the 90s I encountered an architecture
with no ints, and nothing unsigned. Everything was either a
signed floating point value, or a pointer. The superficially
simplest things required quite a bit of hoop jumping (all
done by the C compiler, obviously), but for convolutions
its muladd piplines were the bee's knees.
Tim Rentsch
First, it isn't just trap representations, it's also negative
zeros; the same argument about signal handling applies equally
to both.
Second, there is no reason that the implementation-defined result
of a narrowing conversion (to a signed integer type) can't be a
value that is not representable[*] in the type in question, which
means an exceptional condition, which means undefined behavior,
which means any value at all could be produced, including a trap
representation. Again the same argument applies to negative zeros;
the presence of undefined behavior trumps any other statement of
behavior that the Standard prescribes.
Third, as far as I know (not having a copy of the C90 Standard
handy), C90 didn't talk about either trap representations or
negative zeros, so questions about whether they can be generated
are irrelevant. However, C90 does have similar wording about
out-of-range values being exceptions and causing undefined
behavior, and that's really the important question here --
these kinds of conversions may produce bogus values under C90
as well as under C99.
[*] Notice, for example, the last sentence of 6.2.5p3: "If any
other character is stored in a char object, the resulting value is
implementation-defined but shall be within the range of values
that can be represented in that type." Clearly the final clause
is necessary only if a resulting value might /not/ be within the
range of values that can be represented in the target type.
> As I said, it doesn't seem terribly likely.
Possibly that conclusion came about because of a mistaken
interpretation of the C90 and C99 standards in this area. So if
my comments above are convincing, it might be worth revisiting
that conclusion.
Richard
Before posting one of your typically rude and obnoxious rejoinders you
might try reading the post properly.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Ben Bacarisse
I don't get this part. The bit pattern that /might/ be a negative
zero is either a trap representation or it is a normal value; in which
case it is called negative zero (6.2.6.2 p2). I don't see how signal
handling applies to negative zero. This is an argument about terms,
but they seem to be important ones.
<snip>
--
Ben.
Richard Heathfield
Well, he didn't actually say that, did he? I think the point you are
trying to make with your usual urbane aplomb is that floating-point
numbers in C are represented using sign-magnitude. But the point /he/
made is that -0 is an integer representation. The context seems clear
enough - he was using the term "sign-magnitude" to describe weird but
legal integer representations that he has not personally encountered in
practice (as opposed to the classroom or self-study or whatever). It was
you who introduced floating-point, and it was a bit of a red herring
really, since that isn't even remotely connected to the thrust of his
argument.
> Woh - you've never worked as a DSP programmer.
Do you have any evidence to support that assertion?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Keith Thompson
Nobody said that, or anything resembling it.
The point, I think, is that, even though floating-point formats
typically have a sign bit similar to the one in a sign-and-magnitude,
integer representation, the term "sign-and-magnitude" typically refers
only to signed integers.
It's obvious what Joe and Squeamizh meant unless you choose to
deliberately misinterpret it.
Richard
The wonders of egos and killfiles. Or pretend killfiles. Point now made
at least 3 times.
Is there anything better than a "reg" cat fight?
Keith Thompson
Ok, so it applies only to systems that either have trap
representations for signed integers, or that use a representation
other than two's-complement. Again, there aren't many such systems.
> Second, there is no reason that the implementation-defined result
> of a narrowing conversion (to a signed integer type) can't be a
> value that is not representable[*] in the type in question, which
> means an exceptional condition, which means undefined behavior,
> which means any value at all could be produced, including a trap
> representation. Again the same argument applies to negative zeros;
> the presence of undefined behavior trumps any other statement of
> behavior that the Standard prescribes.
I've assumed that a trap representation cannot represent a value. But
C99 6.2.6.1p5, defining trap representations, says:
Certain object representations need not represent a value of the
object type.
which could be interpreted to mean that a trap representation *can*
represent a value of the type.
I'm not sure what that would mean, though; you wouldn't be able to
access the value without invoking undefined behavior. I suppose the
implementation could define the behavior of accessing a certain trap
representation as yielding a specified value; other operations on it
might have non-standard behavior. For example, addition and
subtraction might work properly on the full range of a type, but
multiplication and division might work only on a smaller subrange.
> Third, as far as I know (not having a copy of the C90 Standard
> handy), C90 didn't talk about either trap representations or
> negative zeros, so questions about whether they can be generated
> are irrelevant. However, C90 does have similar wording about
> out-of-range values being exceptions and causing undefined
> behavior, and that's really the important question here --
> these kinds of conversions may produce bogus values under C90
> as well as under C99.
Both C90 and C99 say that the result of a conversion from an integer
type to a signed integer type yields an implementation-defined result
if the source value can't be represented; C99 additionally allows an
implementation-defined signal to be raised -- which *can* invoke
undefined behavior. So I'd still say that the only way a conversion
can yield a trap representation is if the conversion raises a signal,
and the implementation chooses to define the undefined behavior so
that it stores a trap representation in the target object, which an
ordinary signal handler would have no way of accessing.
Oh, and that raises another point. A trap representation makes sense
only as something stored in an object. A conversion doesn't
necessarily involve any objects, so there's not necessarily any place
for the trap representation to exist.
> [*] Notice, for example, the last sentence of 6.2.5p3: "If any
> other character is stored in a char object, the resulting value is
> implementation-defined but shall be within the range of values
> that can be represented in that type." Clearly the final clause
> is necessary only if a resulting value might /not/ be within the
> range of values that can be represented in the target type.
There are plenty of clauses in the standard that aren't strictly
necessary.
>> As I said, it doesn't seem terribly likely.
>
> Possibly that conclusion came about because of a mistaken
> interpretation of the C90 and C99 standards in this area. So if
> my comments above are convincing, it might be worth revisiting
> that conclusion.
I'm not convinced.
Tim Rentsch
The point I was trying to make is that the same argument
that trap representations can be produced (through an
implementation-defined signal) applies to negative zeros,
so narrowing conversions to signed integer types can
produce negative zero values as results. Some people
are of the opinion that such conversions cannot produce
negative zeros.
Tim Rentsch
Oh, I didn't mean to imply it was common. The question
is does the Standard allow it.
>> Second, there is no reason that the implementation-defined result
>> of a narrowing conversion (to a signed integer type) can't be a
>> value that is not representable[*] in the type in question, which
>> means an exceptional condition, which means undefined behavior,
>> which means any value at all could be produced, including a trap
>> representation. Again the same argument applies to negative zeros;
>> the presence of undefined behavior trumps any other statement of
>> behavior that the Standard prescribes.
>
> I've assumed that a trap representation cannot represent a value. But
> C99 6.2.6.1p5, defining trap representations, says:
>
> Certain object representations need not represent a value of the
> object type.
>
> which could be interpreted to mean that a trap representation *can*
> represent a value of the type.
Since dealing with trap representations is undefined behavior,
an implementation could define any behavior it wanted, including
interpreting it as a legal value (and yes even some of the time
but not all of the time).
> I'm not sure what that would mean, though; you wouldn't be able to
> access the value without invoking undefined behavior. I suppose the
> implementation could define the behavior of accessing a certain trap
> representation as yielding a specified value; other operations on it
> might have non-standard behavior. For example, addition and
> subtraction might work properly on the full range of a type, but
> multiplication and division might work only on a smaller subrange.
One obvious example might be to allow comparison to see
if an object has a trap representation in it, but not
allow any other use. This could be useful for debugging
in an implementation that sets automatic variables without
explicit initializers to trap representations.
>> Third, as far as I know (not having a copy of the C90 Standard
>> handy), C90 didn't talk about either trap representations or
>> negative zeros, so questions about whether they can be generated
>> are irrelevant. However, C90 does have similar wording about
>> out-of-range values being exceptions and causing undefined
>> behavior, and that's really the important question here --
>> these kinds of conversions may produce bogus values under C90
>> as well as under C99.
>
> Both C90 and C99 say that the result of a conversion from an integer
> type to a signed integer type yields an implementation-defined result
> if the source value can't be represented; C99 additionally allows an
> implementation-defined signal to be raised -- which *can* invoke
> undefined behavior. So I'd still say that the only way a conversion
> can yield a trap representation is if the conversion raises a signal,
> and the implementation chooses to define the undefined behavior so
> that it stores a trap representation in the target object, which an
> ordinary signal handler would have no way of accessing.
I'm not aware of any language in the Standard that limits the
word "result" used in 6.3.1.3p3 to be an in-range value for
the target type. Do you have any evidence to support that
contention? Certainly if the result can be anything other
than an in-range value for the target type, then the exceptional
condition/undefined behavior rule would apply.
> Oh, and that raises another point. A trap representation makes sense
> only as something stored in an object. A conversion doesn't
> necessarily involve any objects, so there's not necessarily any place
> for the trap representation to exist.
I think you may have misunderstood my comment. Suppose we're
converting to a 16-bit integer type with a range of -32767..32767.
Suppose the implementation-defined rule for conversions to any signed
integer type yields the same value if the original value is in range
for the target type, and -32768 if the original value is not in range.
Since -32768 is not within the range of what these 16-bit integers
can represent, that's an exceptional condition/undefined behavior.
It's the UB that then causes a trap representation to appear, which
may appear anywhere.
Also, on a practical level, the idea that trap representations don't
make sense outside of "objects" can't be taken very seriously. In
real computers the values produced by arithmetic operations are stored
in some sort of memory that is just as capable (especially for the
case under consideration) of holding a trap representation as it is a
bona fide value.
>> [*] Notice, for example, the last sentence of 6.2.5p3: "If any
>> other character is stored in a char object, the resulting value is
>> implementation-defined but shall be within the range of values
>> that can be represented in that type." Clearly the final clause
>> is necessary only if a resulting value might /not/ be within the
>> range of values that can be represented in the target type.
>
> There are plenty of clauses in the standard that aren't strictly
> necessary.
I won't say there aren't places where this happens, but if it does
it's the exception not the rule. Even if there are other similar
cases, the counter-example in 6.2.5p3 puts the onus of defense on the
side that says the text in 6.3.1.3p3 cannot be an out-of-range value.
All 6.3.1.3p3 says is ".. either the result is implementation-defined
or ..". The word "result" is used frequently in the Standard,
covering all kinds of eventualities, including potential undefined
behavior. Even in cases where the word "result" clealy means a
value, it can mean an out-of-range value, as for example 6.2.5p9:
A computation involving unsigned operands can never overflow,
because a _result_ [emphasis added] 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.
All the evidence I'm aware of suggests that "result" as used
in 6.3.1.3p3 includes the possibility of an out-of-range value.
What evidence is there that it is limited to an in-range value
and cannot be anything else?
Keith Thompson
Well, upthread you did say "To me it does seem likely".
Certainly the standard allows anything for undefined behavior.
I just think that the idea of defining that the result of the
conversion is to raise an implementation-defined signal (something
that's new in C99), and then to have that (implicit?) system
signal handler do something that a user-defined signal handler
couldn't possibly do, is a bit more convoluted than something I'd
expect any actual implementer to do. If were an implementer and
wanted to achieve the same effect, I think I'd just do it in a
non-conforming mode.
>>> Second, there is no reason that the implementation-defined result
>>> of a narrowing conversion (to a signed integer type) can't be a
>>> value that is not representable[*] in the type in question, which
>>> means an exceptional condition, which means undefined behavior,
>>> which means any value at all could be produced, including a trap
>>> representation. Again the same argument applies to negative zeros;
>>> the presence of undefined behavior trumps any other statement of
>>> behavior that the Standard prescribes.
>>
>> I've assumed that a trap representation cannot represent a value. But
>> C99 6.2.6.1p5, defining trap representations, says:
>>
>> Certain object representations need not represent a value of the
>> object type.
>>
>> which could be interpreted to mean that a trap representation *can*
>> represent a value of the type.
>
> Since dealing with trap representations is undefined behavior,
> an implementation could define any behavior it wanted, including
> interpreting it as a legal value (and yes even some of the time
> but not all of the time).
Granted.
>> I'm not sure what that would mean, though; you wouldn't be able to
>> access the value without invoking undefined behavior. I suppose the
>> implementation could define the behavior of accessing a certain trap
>> representation as yielding a specified value; other operations on it
>> might have non-standard behavior. For example, addition and
>> subtraction might work properly on the full range of a type, but
>> multiplication and division might work only on a smaller subrange.
>
> One obvious example might be to allow comparison to see
> if an object has a trap representation in it, but not
> allow any other use. This could be useful for debugging
> in an implementation that sets automatic variables without
> explicit initializers to trap representations.
Agreed.
No, it's not UB; the conversion yields an implementation-defined
result or raises an implementation-defined signal. (The consequences
of the signal might be undefined.)
> It's the UB that then causes a trap representation to appear, which
> may appear anywhere.
Only if the behavior is actually undefined, and only if the
implementation takes advantage of it.
> Also, on a practical level, the idea that trap representations don't
> make sense outside of "objects" can't be taken very seriously. In
> real computers the values produced by arithmetic operations are stored
> in some sort of memory that is just as capable (especially for the
> case under consideration) of holding a trap representation as it is a
> bona fide value.
But in the abstract machine, I don't believe trap representations can
exist other than in objects.
I'll have to think about that. (Or, to be honest, I might not get
around to it.)
Tim Rentsch
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Tim Rentsch <t...@alumni.caltech.edu> writes:
>>>>>>>> [snip,snip,snip]
Are you trying to say that when or if your future deliberations
produce a result you'll get back to us?
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> Squeamizh <squ...@hotmail.com> writes:
>>> 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.
>>
>> The real world has nothing to do with floating point?
>
> Nobody said that, or anything resembling it.
You obviously speak a different language on your side of the pond.
Look up 'demonstrative pronoun'.
Phil
Richard
> Keith Thompson <ks...@mib.org> writes:
>> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>>> Squeamizh <squ...@hotmail.com> writes:
>>>> 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.
>>>
>>> The real world has nothing to do with floating point?
>>
>> Nobody said that, or anything resembling it.
>
> You obviously speak a different language on your side of the pond.
> Look up 'demonstrative pronoun'.
>
> Phil
You snipped the text to cover your mistake. And it was a mistake on both
sides of the pond.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>>> Squeamizh <squ...@hotmail.com> writes:
>>>> 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.
>>>
>>> The real world has nothing to do with floating point?
>>
>> Nobody said that, or anything resembling it.
>
> You obviously speak a different language on your side of the pond.
> Look up 'demonstrative pronoun'.
Ok, fine, a literal reading might indicate that Squeamizh was saying
that real world has nothing to do with floating point. It was
*extremely* obvious from the context that that wasn't what he meant.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Tim Rentsch <t...@alumni.caltech.edu> writes:
>>> All the evidence I'm aware of suggests that "result" as used
>>> in 6.3.1.3p3 includes the possibility of an out-of-range value.
>>> What evidence is there that it is limited to an in-range value
>>> and cannot be anything else?
>>
>> I'll have to think about that. (Or, to be honest, I might not get
>> around to it.)
>
> Are you trying to say that when or if your future deliberations
> produce a result you'll get back to us?
I make no commitment.
Tim Rentsch
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Tim Rentsch <t...@alumni.caltech.edu> writes:
> [...]
>>>> All the evidence I'm aware of suggests that "result" as used
>>>> in 6.3.1.3p3 includes the possibility of an out-of-range value.
>>>> What evidence is there that it is limited to an in-range value
>>>> and cannot be anything else?
>>>
>>> I'll have to think about that. (Or, to be honest, I might not get
>>> around to it.)
>>
>> Are you trying to say that when or if your future deliberations
>> produce a result you'll get back to us?
>
> I make no commitment.
Sorry, I should have added a smiley. I was making a
joke on the word "result".
Lowell Gilbert
> Tim Rentsch <t...@alumni.caltech.edu> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Tim Rentsch <t...@alumni.caltech.edu> writes:
> [...]
>>>> All the evidence I'm aware of suggests that "result" as used
>>>> in 6.3.1.3p3 includes the possibility of an out-of-range value.
>>>> What evidence is there that it is limited to an in-range value
>>>> and cannot be anything else?
>>>
>>> I'll have to think about that. (Or, to be honest, I might not get
>>> around to it.)
>>
>> Are you trying to say that when or if your future deliberations
>> produce a result you'll get back to us?
>
> I make no commitment.
You mean there may be no object representation?
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/
Michael Foukarakis
> Tim Rentsch <t...@alumni.caltech.edu> writes:
> > Keith Thompson <ks...@mib.org> writes:
> >> Tim Rentsch <t...@alumni.caltech.edu> writes:
> [...]
> >>> All the evidence I'm aware of suggests that "result" as used
> >>> in 6.3.1.3p3 includes the possibility of an out-of-range value.
> >>> What evidence is there that it is limited to an in-range value
> >>> and cannot be anything else?
>
> >> I'll have to think about that. (Or, to be honest, I might not get
> >> around to it.)
>
> > Are you trying to say that when or if your future deliberations
> > produce a result you'll get back to us?
>
> I make no commitment.
Is the matter undefined or unspecified?
Phil Carmody
> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Phil Carmody <thefatphi...@yahoo.co.uk> writes:
>>>> Squeamizh <squ...@hotmail.com> writes:
>>>>> 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.
>>>>
>>>> The real world has nothing to do with floating point?
>>>
>>> Nobody said that, or anything resembling it.
>>
>> You obviously speak a different language on your side of the pond.
>> Look up 'demonstrative pronoun'.
>
> Ok, fine, a literal reading might indicate that Squeamizh was saying
> that real world has nothing to do with floating point.
Yup.
> It was
> *extremely* obvious from the context that that wasn't what he meant.
Hmmm... I think you'll find that one of us (not me) introduced
an absolute ('nothing'), and that when there's doubt the absolute
almost always tends to be false.