plain int and signed int

Discussion in 'C Programming' started by happy, Jan 14, 2010.

  1. happy

    happy Guest

    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?
    happy, Jan 14, 2010
    #1
    1. Advertising

  2. On 14 Jan, 09:03, happy <> 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
    Nick Keighley, Jan 14, 2010
    #2
    1. Advertising

  3. happy <> 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.

    "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) <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, Jan 14, 2010
    #3
  4. happy

    happy Guest

    On Jan 14, 10:22 pm, Keith Thompson <> wrote:
    > happy <> 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.
    >

    Even if plain char is signed, then also are plain and signed char
    distinct ?
    I mean can they have different representations?
    happy, Jan 14, 2010
    #4
  5. happy

    Ben Pfaff Guest

    happy <> writes:

    > 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_
    Ben Pfaff, Jan 14, 2010
    #5
  6. happy

    Eric Sosman Guest

    On 1/14/2010 12:49 PM, happy wrote:
    > On Jan 14, 10:22 pm, Keith Thompson<> wrote:
    >> happy<> 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.
    >>

    > Even if plain char is signed, then also are plain and signed char
    > distinct ?
    > I mean can they have different representations?


    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
    lid
    Eric Sosman, Jan 14, 2010
    #6
  7. happy <> writes:
    > On Jan 14, 10:22 pm, Keith Thompson <> wrote:
    >> happy <> 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.
    >>

    > Even if plain char is signed, then also are plain and signed char
    > distinct ?


    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)

    --
    Keith Thompson (The_Other_Keith) <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, Jan 14, 2010
    #7
  8. happy

    bartc Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > Nick Keighley wrote:
    >> On 14 Jan, 09:03, happy <> 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
    bartc, Jan 15, 2010
    #8
  9. happy

    Guest

    bartc <> 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.
    --
    Larry Jones

    I don't think that question was very hypothetical at all. -- Calvin
    , Jan 15, 2010
    #9
  10. writes:
    > bartc <> 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?

    --
    Keith Thompson (The_Other_Keith) <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, Jan 16, 2010
    #10
  11. On 2010-01-16, Keith Thompson <> wrote:
    > writes:
    >> bartc <> 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?
    Andrew Poelstra, Jan 16, 2010
    #11
  12. Andrew Poelstra <> writes:
    > On 2010-01-16, Keith Thompson <> wrote:
    >> writes:
    >>> bartc <> 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) <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, Jan 16, 2010
    #12
  13. happy

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > writes:
    >> bartc <> 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, Jan 16, 2010
    #13
  14. happy

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Andrew Poelstra <> writes:
    >> On 2010-01-16, Keith Thompson <> wrote:
    >>> writes:
    >>>> bartc <> 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.
    Tim Rentsch, Jan 16, 2010
    #14
  15. happy

    bartc Guest

    "Keith Thompson" <> wrote in message
    news:...
    > writes:
    >> bartc <> 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
    bartc, Jan 16, 2010
    #15
  16. happy

    Tim Rentsch Guest

    pete <> writes:

    > Tim Rentsch wrote:
    >> Keith Thompson <> writes:
    >>
    >>
    >>>Andrew Poelstra <> writes:
    >>>
    >>>>On 2010-01-16, Keith Thompson <> wrote:
    >>>>
    >>>>> writes:
    >>>>>
    >>>>>>bartc <> 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, Jan 16, 2010
    #16
  17. happy

    Tim Rentsch Guest

    "bartc" <> writes:

    > "Keith Thompson" <> wrote in message
    > news:...
    >> writes:
    >>> bartc <> 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.
    Tim Rentsch, Jan 16, 2010
    #17
  18. happy

    Eric Sosman Guest

    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.


    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
    lid
    Eric Sosman, Jan 16, 2010
    #18
  19. happy

    Phil Carmody Guest

    pete <> writes:
    > Tim Rentsch wrote:
    >> Keith Thompson <> writes:
    >>>Andrew Poelstra <> writes:
    >>>>On 2010-01-16, Keith Thompson <> wrote:
    >>>>> writes:
    >>>>>>bartc <> 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
    Phil Carmody, Jan 16, 2010
    #19
  20. happy

    Tim Rentsch Guest

    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.
    Tim Rentsch, Jan 16, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Siemel Naran

    convert signed int to unsigned int

    Siemel Naran, Nov 28, 2004, in forum: C++
    Replies:
    3
    Views:
    34,050
    Ioannis Vranos
    Nov 29, 2004
  2. Schnoffos
    Replies:
    2
    Views:
    1,194
    Martien Verbruggen
    Jun 27, 2003
  3. Hal Styli
    Replies:
    14
    Views:
    1,608
    Old Wolf
    Jan 20, 2004
  4. Alex
    Replies:
    3
    Views:
    638
    Michael Mair
    Apr 26, 2006
  5. V.Subramanian, India

    no warning for assigning unsigned int to plain int

    V.Subramanian, India, Oct 12, 2011, in forum: C Programming
    Replies:
    5
    Views:
    569
    Keith Thompson
    Oct 12, 2011
Loading...

Share This Page