integral promotion., sign extension

Discussion in 'C Programming' started by mohangupta13, Jun 1, 2010.

  1. mohangupta13

    mohangupta13 Guest

    Well i had a though time extracting information from previous threads
    on the above three topics ....its soo much information and it creates
    more confusion ...
    kindly guide me to some well written articles on these topics...
    1. Integral promotion :

    What i understand: " If two types are intermixed then the type with
    smaller capacity is promoted to the type with the larger capacity" ..i
    am sure i am wrong here .

    2. Sign extension:

    what i understand: whenever say a char is promoted to int the msb of
    char is copied in the extra bits in the msb of the int ...i.e char=
    10010111---> 1111111110010111 (in int)...

    3. Unsigned or signed character : what i understand is that if you
    declare char a=10; then 'a' is supposed to be signed character by
    default as no explicit unsigned qualifier was attached ..but some
    threads say its implementation define ...confusion here???

    Thanks in advance ...
    Mohan Gupta
     
    mohangupta13, Jun 1, 2010
    #1
    1. Advertising

  2. mohangupta13

    kathir Guest

    On Jun 1, 9:57 am, mohangupta13 <> wrote:
    > Well i had a though time extracting information from previous threads
    > on the above three topics ....its soo much information and it creates
    > more confusion ...
    >  kindly guide me to some well written articles on these topics...
    > 1. Integral promotion :
    >
    > What i understand: " If two types are intermixed then the type with
    > smaller capacity is promoted to the type with the larger capacity" ..i
    > am sure i am wrong here .
    >
    > 2. Sign extension:
    >
    > what i understand: whenever say a char is promoted to int the msb of
    > char is copied in the extra bits in the msb of the int ...i.e char=
    > 10010111---> 1111111110010111 (in int)...
    >
    > 3. Unsigned or signed character : what i understand is that if you
    > declare char a=10; then 'a' is supposed to be signed character by
    > default as no explicit unsigned qualifier was attached ..but some
    > threads say its implementation define ...confusion here???
    >
    > Thanks in advance ...
    > Mohan Gupta


    Regarding Unsigned or signed character:
    Project Configuration -> C/C++ -> Language tab, you can set the value
    for "Default Char Unsigned". When you create a project, it would be
    set to No by default. You can change it to Yes, if you want. The
    compilter switch would be /J.

    Thanks and Regards,
    Kathir
    http://www.softwareandfinance.com/
     
    kathir, Jun 1, 2010
    #2
    1. Advertising

  3. mohangupta13

    mohangupta13 Guest

    On Jun 1, 10:17 pm, kathir <> wrote:
    > On Jun 1, 9:57 am, mohangupta13 <> wrote:
    >
    >
    >
    > > Well i had a though time extracting information from previous threads
    > > on the above three topics ....its soo much information and it creates
    > > more confusion ...
    > >  kindly guide me to some well written articles on these topics...
    > > 1. Integral promotion :

    >
    > > What i understand: " If two types are intermixed then the type with
    > > smaller capacity is promoted to the type with the larger capacity" ..i
    > > am sure i am wrong here .

    >
    > > 2. Sign extension:

    >
    > > what i understand: whenever say a char is promoted to int the msb of
    > > char is copied in the extra bits in the msb of the int ...i.e char=
    > > 10010111---> 1111111110010111 (in int)...

    >
    > > 3. Unsigned or signed character : what i understand is that if you
    > > declare char a=10; then 'a' is supposed to be signed character by
    > > default as no explicit unsigned qualifier was attached ..but some
    > > threads say its implementation define ...confusion here???

    >
    > > Thanks in advance ...
    > > Mohan Gupta

    >
    > Regarding Unsigned or signed character:
    > Project Configuration -> C/C++ -> Language tab, you can set the value
    > for "Default Char Unsigned". When you create a project, it would be
    > set to No by default. You can change it to Yes, if you want. The
    > compilter switch would be /J.

    What i am asking is why not like int a declaration of "char a" just
    not mean an signed char ..why is it implementation defined (if its
    really so )??..as "int a " mean 'a' is "signed int" .
    >
    > Thanks and Regards,
    > Kathirhttp://www.softwareandfinance.com/
     
    mohangupta13, Jun 1, 2010
    #3
  4. mohangupta13

    dbtid Guest

    kathir wrote:


    > Regarding Unsigned or signed character:
    > Project Configuration -> C/C++ -> Language tab, you can set the value
    > for "Default Char Unsigned". When you create a project, it would be
    > set to No by default. You can change it to Yes, if you want. The
    > compilter switch would be /J.


    Gee, I can't find anything like "Project Configuration" ANYWHERE on my
    computer!!! What do I do? Does this mean I can't program in C?

    You might consider it wiser to refrain from posting such details from a
    specific tool when answering questions in c.l.c.
     
    dbtid, Jun 1, 2010
    #4
  5. mohangupta13

    dbtid Guest

    mohangupta13 wrote:
    > Well i had a though time extracting information from previous threads
    > on the above three topics ....its soo much information and it creates
    > more confusion ...
    > kindly guide me to some well written articles on these topics...
    > 1. Integral promotion :
    >
    > What i understand: " If two types are intermixed then the type with
    > smaller capacity is promoted to the type with the larger capacity" ..i
    > am sure i am wrong here .
    >
    > 2. Sign extension:
    >
    > what i understand: whenever say a char is promoted to int the msb of
    > char is copied in the extra bits in the msb of the int ...i.e char=
    > 10010111---> 1111111110010111 (in int)...
    >
    > 3. Unsigned or signed character : what i understand is that if you
    > declare char a=10; then 'a' is supposed to be signed character by
    > default as no explicit unsigned qualifier was attached ..but some
    > threads say its implementation define ...confusion here???
    >
    > Thanks in advance ...
    > Mohan Gupta


    Do you have a copy of the standard, or perhaps a draft copy?
    They both do a pretty good job of explaining how things are supposed to
    be converted.

    For 1) your concept of going from less capacity to more capacity is
    intuitively correct. When mixing expressions with, say, doubles and
    ints, ints are converted to doubles to maintain precision.

    For 2) I think it depends on whether you're dealing with a signed or
    unsigned character type. For example:

    char a = -2;
    int x = a;
    printf ("x = %d\n", x);

    can print out 'x = -2';

    Then

    unsigned char a = -2;
    int x = a;
    printf ("x = %d\n", x);

    can print out 'x = 254'

    So it depends on whether char is treated is signed or unsigned.

    For 3) See ISO/IEC 9899:1999, Section J.3 "Implementation-defined
    behavior", J.3.4 "Characters":

    Which of signed char or unsigned char has the same range,
    representation, and behavior as ‘‘plain’’ char (6.2.5, 6.3.1.1).

    What that boils down to is that it's up to the implementation on how to
    treat 'char' variables. Implementors are free to choose signed or
    unsigned behavior when dealing with the 'char' type. Every
    implementation I'm aware of gives a way to tell the compiler what
    behavior YOU want it to use.

    Best wishes to you.

    dbtid
     
    dbtid, Jun 1, 2010
    #5
  6. mohangupta13

    Richard Bos Guest

    kathir <> wrote:

    > On Jun 1, 9:57=A0am, mohangupta13 <> wrote:


    > > =A0kindly guide me to some well written articles on these topics...


    K&R, K&R, K&R. Always start at K&R. If they don't solve your problem,
    either you need more detail from the Standard, or you don't actually
    have the problem you think you have.

    > > 1. Integral promotion :
    > >
    > > What i understand: " If two types are intermixed then the type with
    > > smaller capacity is promoted to the type with the larger capacity" ..i
    > > am sure i am wrong here .


    Well... in essence, you're right. The devil is in the details. The
    details can be found in the Standard.

    > > 2. Sign extension:
    > >
    > > what i understand: whenever say a char is promoted to int the msb of
    > > char is copied in the extra bits in the msb of the int ...i.e char=3D
    > > 10010111---> 1111111110010111 (in int)...


    No. For the time being, forget about the representation of integers in
    bits, signed or unsigned. All integer conversions are done _by value_,
    not by representation. And converting char to int is (unless you have a
    _very_ unusual implementation) very simple: the value of the resulting
    int is the same as the value the char had.
    How that value is represented in bits is not really relevant to this.
    The only things you need to remember are: if the value fits, it fits; if
    the value doesn't fit in an unsigned integer (_not_ just unsigned int,
    any unsigned integer) it is made to fit; if it doesn't fit in a signed
    integer, the result is implementation-defined or raises a signal (which
    may have UB, so don't do it).

    > > 3. Unsigned or signed character : what i understand is that if you
    > > declare char a=3D10; then 'a' is supposed to be signed character by
    > > default as no explicit unsigned qualifier was attached ..but some
    > > threads say its implementation define ...confusion here???


    > Regarding Unsigned or signed character:
    > Project Configuration -> C/C++ -> Language tab,


    Funny, I don't have a project called Configuration. And the only
    Languages tab I can find is in Open Office, where it selects the
    language the spellcheck uses. Presumably if you have Chinese installed
    that uses characters, but not in English or Dutch.

    Richard
     
    Richard Bos, Jun 1, 2010
    #6
  7. mohangupta13

    Eric Sosman Guest

    On 6/1/2010 12:57 PM, mohangupta13 wrote:
    > Well i had a though time extracting information from previous threads
    > on the above three topics ....its soo much information and it creates
    > more confusion ...
    > kindly guide me to some well written articles on these topics...
    > 1. Integral promotion :
    >
    > What i understand: " If two types are intermixed then the type with
    > smaller capacity is promoted to the type with the larger capacity" ..i
    > am sure i am wrong here .


    What you've described is, loosely, the "usual arithmetic
    conversions." Most arithmetic operators in C require that their
    operands be of the same type, because most CPU's on which C code
    runs have a similar requirement. Few CPU's can add an int to a
    double, or compare a long to a short; they can add two doubles or
    compare two longs, but can't work directly with mixed types.

    When you as a programmer need to add an int to a double, what
    must you do? You could convert the double to an int and add the
    two ints, or you could convert the int to a double and add the two
    doubles, or you could convert both operands to long double and add
    those, or ... The usual arithmetic conversions tell you what C
    will do when presented with mixed operands (I'm considering only
    the arithmetic operands here, not pointers):

    - If either is a long double, the other converts to long double.

    - Otherwise, if either is a double, the other converts to double.

    - Otherwise, if either is a float, the other converts to float.

    - Otherwise, both operands are integers of some kind, and the
    story continues below ...

    There's also something called the "integer promotions," which
    exist because many CPU's can perform arithmetic only on integers of
    a few "widths." For example, a CPU that does all integer arithmetic
    in registers may have no instructions for doing arithmetic on char
    values: You fetch the char into a register (widening it as you go),
    do the arithmetic in the wide register, and store (part of) the
    result back in the char variable again. The integer promotions are
    C's description of this kind of conversion (which happens almost
    every time "narrow" integer is used, not just with mixed types):

    - If the integer is "narrower" than int *and* if the range of
    int includes the entire range of the original type, the
    integer converts to (promotes to) int.

    - If the integer is "narrower" than int *and* if some values
    of the original type are out of range for int, the integer
    converts to unsigned int.

    - All other integer types (including int and unsigned int
    themselves) are left unpromoted.

    We return now to the usual arithmetic conversions, where we've
    already covered the floating-point cases and are left with operands
    of integer types. C applies the integer promotions to both operands,
    which may resolve the type mismatch right there: a char and a short
    might both promote to int, for example, and the types are no longer
    mixed (it needn't always happen this way; see below). But if a
    mismatch still exists:

    - If both operand types have the same "signedness" -- both signed
    or both unsigned -- the "narrower" operand converts to the type
    of the "wider."

    - Otherwise, we have one signed and one unsigned type. If the
    signed type is "narrower" than the unsigned type, the signed
    operand converts to the unsigned type. (This will change the
    numeric value if the signed operand was negative.)

    - Otherwise, if the range of the signed type includes all possible
    values of the unsigned type, the unsigned type converts to the
    signed type.

    - Otherwise, we've got a signed type that is "wider" than the
    unsigned type but can't represent all values of the unsigned
    type. (This sounds like a contradiction, but it's not C's
    fault: I've been using terms like "wide" and "narrow," and
    they're just loose terms. The formal definition of C uses a
    scheme of "integer conversion ranks" to describe this stuff
    precisely, but I thought that dragging that intricate business
    in would be more confusing than enlightening. Stick with "wide"
    and "narrow" for now, and promise yourself that you'll look up
    "integer conversion rank" later, when you're more secure.)
    Anyhow, if we get to this seemingly contradictory situation,
    both operands convert to the unsigned type of the same width
    as the signed type (e.g., long + uint64_t might promote both
    operands to unsigned long).

    ... and *that* covers both the usual arithmetic conversions and
    the integer promotions. I've simplified a bit by using "wide" and
    "narrow" and waving my hands a little, and I've also ignored complex
    arithmetic, but I hope it's enough to get you started.

    > 2. Sign extension:
    >
    > what i understand: whenever say a char is promoted to int the msb of
    > char is copied in the extra bits in the msb of the int ...i.e char=
    > 10010111---> 1111111110010111 (in int)...


    Only on some machines. There are three things going on here:

    First, each system makes its own decision as to whether plain char
    is a signed type or an unsigned type. Since promoting an unsigned type
    to a wider type (signed or unsigned) preserves the value, the sign
    extension you describe won't happen on a system that chooses to treat
    char as unsigned.

    Second, each system makes its own decision about how to represent
    negative integers. By far the most common is the two's complement
    scheme you illustrate, but C also allows two other schemes, ones'
    complement and signed magnitude. In a signed magnitude scheme, the
    sign bit simply "relocates" during widening; it doesn't "propagate."

    Third, each system makes its own decision about how wide the
    various integer types are. There are some limits on what can be
    chosen, but it is possible for char and int to have the same width
    (this is said to be common practice in CPU's that specialize in digital
    signal processing). On such a system, if char is taken to be unsigned,
    a review of the integer promotions above will show that char promotes
    to unsigned int, not to int. So you've got an unsigned char that
    promotes to an unsigned int -- unsigned all the way, so there's no
    "sign" to be manipulated in the first place.

    > 3. Unsigned or signed character : what i understand is that if you
    > declare char a=10; then 'a' is supposed to be signed character by
    > default as no explicit unsigned qualifier was attached ..but some
    > threads say its implementation define ...confusion here???


    The signedness of plain char is implementation-defined, as
    mentioned above. This is C's recognition of the fact that some
    CPU's like to treat characters as small signed integers, while
    others treat them as little bunches of bits, nominally unsigned.
    If you're using char to store numeric data (as opposed to things
    that are notionally "just character codes,") you should probably
    specify signed char or unsigned char, since unadorned char will
    behave differently on different systems.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jun 1, 2010
    #7
  8. mohangupta13

    Guest

    mohangupta13 <> wrote:
    >
    > What i am asking is why not like int a declaration of "char a" just
    > not mean an signed char ..why is it implementation defined (if its
    > really so )??..as "int a " mean 'a' is "signed int" .


    Historical reasons. "Plain" char is supposed to be suitable for
    representing ordinary characters, which are supposed to have
    non-negative values. On ASCII systems where the ordinary characters
    have the top bit zero, it's common to make char signed (like plain int
    is signed) because it is (or was) more efficient in most cases. But on
    systems that use other character sets (like EBCDIC), some of the
    ordinary characters have the top bit set and would be negative if char
    were signed, so it's not signed on those systems.
    --
    Larry Jones

    Oh, what the heck. I'll do it. -- Calvin
     
    , Jun 1, 2010
    #8
  9. mohangupta13

    Eric Sosman Guest

    On 6/1/2010 4:09 PM, wrote:
    > mohangupta13<> wrote:
    >>
    >> What i am asking is why not like int a declaration of "char a" just
    >> not mean an signed char ..why is it implementation defined (if its
    >> really so )??..as "int a " mean 'a' is "signed int" .

    >
    > Historical reasons. "Plain" char is supposed to be suitable for
    > representing ordinary characters, which are supposed to have
    > non-negative values. On ASCII systems where the ordinary characters
    > have the top bit zero, it's common to make char signed (like plain int
    > is signed) because it is (or was) more efficient in most cases. But on
    > systems that use other character sets (like EBCDIC), some of the
    > ordinary characters have the top bit set and would be negative if char
    > were signed, so it's not signed on those systems.


    One would have to check with DMR and friends, but I'd imagine
    efficiency had something to do with the matter. On a PDP-11, say,
    the MOVB instruction that loads a byte into a register treats it
    as a small integer and extends the sign. But on S/360 the IC
    instruction replaces a register's low-order bits with a byte from
    memory, doing no sign extension (in fact, leaving the high-order
    24 bits undisturbed). So:

    - If char were required to be signed, PDP-11 would love it
    but S/360 would need extra instructions to propagate the
    sign (maybe two shifts: 24 to the left and 24 to the right).

    - If char were required to be unsigned, S/360 would be happy
    but PDP-11 would be penalized with extra code (perhaps an
    AND after each fetch).

    Since C programs did a lot of character manipulation (and still
    do), the penalty of extra code on every character access might well
    have been too much to swallow. A C that dictated the signedness of
    char might have wound up as "a language for DEC machines that's real
    slow on IBM" or vice versa. Similar considerations very likely
    applied to other machines that were attractive targets for C. Had
    C insisted on one signedness or the other, it might have been a good
    deal less successful than it in fact became.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jun 1, 2010
    #9
  10. On Tue, 1 Jun 2010 09:57:01 -0700 (PDT), mohangupta13
    <> wrote:

    >Well i had a though time extracting information from previous threads
    >on the above three topics ....its soo much information and it creates
    >more confusion ...
    > kindly guide me to some well written articles on these topics...
    >1. Integral promotion :
    >
    >What i understand: " If two types are intermixed then the type with
    >smaller capacity is promoted to the type with the larger capacity" ..i
    >am sure i am wrong here .


    This is true if the two types have the same signedness. If one is
    unsigned and the other signed, it becomes a little more complicated.

    Why don't you download n1256 which explains both the "usual arithmetic
    conversions" and the "integer promotions" pretty clearly.

    >
    >2. Sign extension:
    >
    >what i understand: whenever say a char is promoted to int the msb of
    >char is copied in the extra bits in the msb of the int ...i.e char=
    >10010111---> 1111111110010111 (in int)...


    You are discussing how a value is represented. That is not the issue.
    When a char is promoted to int, the value is unchanged. If the
    hardware uses a signed magnitude representation, then the sign bit is
    not extended.

    You really shouldn't care unless you are writing code that depends on
    a particular representation. If you are, you should be asking in a
    newsgroup devoted to your system since it is not really a language
    issue.

    >
    >3. Unsigned or signed character : what i understand is that if you
    >declare char a=10; then 'a' is supposed to be signed character by
    >default as no explicit unsigned qualifier was attached ..but some
    >threads say its implementation define ...confusion here???


    There are three distinct types, char, signed char, and unsigned char.
    char is guaranteed to be equivalent to one of the other two but it is
    up to the implementation developer to chose which one.

    The decision is usually based on how characters are represented.
    Windows systems have char equivalent to signed char. IBM mainframes,
    where letters and numbers have the high order bit set (A is
    represented by 11000001) have char equivalent to unsigned char so that
    A will compare less than B.

    --
    Remove del for email
     
    Barry Schwarz, Jun 2, 2010
    #10
  11. mohangupta13

    mohangupta13 Guest

    On Jun 2, 8:48 am, Barry Schwarz <> wrote:
    > On Tue, 1 Jun 2010 09:57:01 -0700 (PDT), mohangupta13
    >
    > <> wrote:
    > >Well i had a though time extracting information from previous threads
    > >on the above three topics ....its soo much information and it creates
    > >more confusion ...
    > > kindly guide me to some well written articles on these topics...
    > >1. Integral promotion :

    >
    > >What i understand: " If two types are intermixed then the type with
    > >smaller capacity is promoted to the type with the larger capacity" ..i
    > >am sure i am wrong here .

    >
    > This is true if the two types have the same signedness.  If one is
    > unsigned and the other signed, it becomes a little more complicated.
    >
    > Why don't you download n1256 which explains both the "usual arithmetic
    > conversions" and the "integer promotions" pretty clearly.
    >
    >
    >
    > >2. Sign extension:

    >
    > >what i understand: whenever say a char is promoted to int the msb of
    > >char is copied in the extra bits in the msb of the int ...i.e char=
    > >10010111---> 1111111110010111 (in int)...

    >
    > You are discussing how a value is represented.  That is not the issue.
    > When a char is promoted to int, the value is unchanged.  If the
    > hardware uses a signed magnitude representation, then the sign bit is
    > not extended.  
    >
    > You really shouldn't care unless you are writing code that depends on
    > a particular representation.  If you are, you should be asking in a
    > newsgroup devoted to your system since it is not really a language
    > issue.
    >
    >
    >
    > >3. Unsigned or signed character : what i understand is that if you
    > >declare char a=10; then 'a' is supposed to be signed character by
    > >default as no explicit unsigned qualifier was attached ..but some
    > >threads say its implementation define ...confusion here???

    >
    > There are three distinct types, char, signed char, and unsigned char.
    > char is guaranteed to be equivalent to one of the other two but it is
    > up to the implementation developer to chose which one.  
    >
    > The decision is usually based on how characters are represented.
    > Windows systems have char equivalent to signed char.  IBM mainframes,
    > where letters and numbers have the high order bit set (A is
    > represented by 11000001) have char equivalent to unsigned char so that
    > A will compare less than B.
    >
    > --
    > Remove del for email


    Thank you all for your time and effort . Thanks a lot !!.
    Mohan
     
    mohangupta13, Jun 2, 2010
    #11
  12. mohangupta13

    Tim Rentsch Guest

    Eric Sosman <> writes:

    > On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>[snip]

    >
    > There's also something called the "integer promotions," which
    > exist because many CPU's can perform arithmetic only on integers of
    > a few "widths." For example, a CPU that does all integer arithmetic
    > in registers may have no instructions for doing arithmetic on char
    > values: You fetch the char into a register (widening it as you go),
    > do the arithmetic in the wide register, and store (part of) the
    > result back in the char variable again. The integer promotions are
    > C's description of this kind of conversion (which happens almost
    > every time "narrow" integer is used, not just with mixed types):
    >
    > - If the integer is "narrower" than int *and* if the range of
    > int includes the entire range of the original type, the
    > integer converts to (promotes to) int.


    Narrower than int, /or/ the same width as int (per n1256).
     
    Tim Rentsch, Jun 18, 2010
    #12
  13. On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
    <> wrote:

    >Eric Sosman <> writes:
    >
    >> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>>[snip]

    >>
    >> There's also something called the "integer promotions," which
    >> exist because many CPU's can perform arithmetic only on integers of
    >> a few "widths." For example, a CPU that does all integer arithmetic
    >> in registers may have no instructions for doing arithmetic on char
    >> values: You fetch the char into a register (widening it as you go),
    >> do the arithmetic in the wide register, and store (part of) the
    >> result back in the char variable again. The integer promotions are
    >> C's description of this kind of conversion (which happens almost
    >> every time "narrow" integer is used, not just with mixed types):
    >>
    >> - If the integer is "narrower" than int *and* if the range of
    >> int includes the entire range of the original type, the
    >> integer converts to (promotes to) int.

    >
    >Narrower than int, /or/ the same width as int (per n1256).


    While the result is the same, the requirement to convert is specified
    in terms of rank, not width (6.3.1.1-2).

    --
    Remove del for email
     
    Barry Schwarz, Jun 19, 2010
    #13
  14. mohangupta13

    Tim Rentsch Guest

    Barry Schwarz <> writes:

    > On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
    > <> wrote:
    >
    >>Eric Sosman <> writes:
    >>
    >>> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>>>[snip]
    >>>
    >>> There's also something called the "integer promotions," which
    >>> exist because many CPU's can perform arithmetic only on integers of
    >>> a few "widths." For example, a CPU that does all integer arithmetic
    >>> in registers may have no instructions for doing arithmetic on char
    >>> values: You fetch the char into a register (widening it as you go),
    >>> do the arithmetic in the wide register, and store (part of) the
    >>> result back in the char variable again. The integer promotions are
    >>> C's description of this kind of conversion (which happens almost
    >>> every time "narrow" integer is used, not just with mixed types):
    >>>
    >>> - If the integer is "narrower" than int *and* if the range of
    >>> int includes the entire range of the original type, the
    >>> integer converts to (promotes to) int.

    >>
    >>Narrower than int, /or/ the same width as int (per n1256).

    >
    > While the result is the same, the requirement to convert is specified
    > in terms of rank, not width (6.3.1.1-2).


    That's right, and the distinction is important, because
    different types can have the same width but still have
    different ranks. I used the "narrower" description
    because the posting I was responding to did; probably
    I should have put it in quotes like it was before.
    In any event, thank you for the clarification.
     
    Tim Rentsch, Jun 20, 2010
    #14
  15. On Sun, 20 Jun 2010 00:36:03 -0700, Tim Rentsch
    <> wrote:

    >Barry Schwarz <> writes:
    >
    >> On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
    >> <> wrote:
    >>
    >>>Eric Sosman <> writes:
    >>>
    >>>> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>>>>[snip]
    >>>>
    >>>> There's also something called the "integer promotions," which
    >>>> exist because many CPU's can perform arithmetic only on integers of
    >>>> a few "widths." For example, a CPU that does all integer arithmetic
    >>>> in registers may have no instructions for doing arithmetic on char
    >>>> values: You fetch the char into a register (widening it as you go),
    >>>> do the arithmetic in the wide register, and store (part of) the
    >>>> result back in the char variable again. The integer promotions are
    >>>> C's description of this kind of conversion (which happens almost
    >>>> every time "narrow" integer is used, not just with mixed types):
    >>>>
    >>>> - If the integer is "narrower" than int *and* if the range of
    >>>> int includes the entire range of the original type, the
    >>>> integer converts to (promotes to) int.
    >>>
    >>>Narrower than int, /or/ the same width as int (per n1256).

    >>
    >> While the result is the same, the requirement to convert is specified
    >> in terms of rank, not width (6.3.1.1-2).

    >
    >That's right, and the distinction is important, because
    >different types can have the same width but still have
    >different ranks. I used the "narrower" description
    >because the posting I was responding to did; probably
    >I should have put it in quotes like it was before.
    >In any event, thank you for the clarification.


    Ignoring the differences between signed and unsigned integers, it is
    required that a higher rank integer be able to represent all the
    values of a lower rank integer. This is normally taken to mean the
    higher rank integer is at least as big as the lower rank one. It
    seems to me that the preceding statement must be true if one considers
    only the value bits in the bytes the objects occupy and disregard any
    padding bits.

    But sizeof includes the padding bits it its evaluation. So the
    question becomes: Is it possible for a lower rank integer to have
    enough padding bits so that it is actually larger than the higher rank
    one? On a perverse system with 8-bit bytes, could INT_MAX be
    2147483647, SHRT_MAX be 32767, sizeof(int) be 4, and sizeof(short) be
    6 (16 value bits and 32 padding bits)?

    --
    Remove del for email
     
    Barry Schwarz, Jun 20, 2010
    #15
  16. mohangupta13

    Eric Sosman Guest

    On 6/18/2010 2:13 PM, Tim Rentsch wrote:
    > Eric Sosman<> writes:
    >
    >> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>> [snip]

    >>
    >> There's also something called the "integer promotions," which
    >> exist because many CPU's can perform arithmetic only on integers of
    >> a few "widths." For example, a CPU that does all integer arithmetic
    >> in registers may have no instructions for doing arithmetic on char
    >> values: You fetch the char into a register (widening it as you go),
    >> do the arithmetic in the wide register, and store (part of) the
    >> result back in the char variable again. The integer promotions are
    >> C's description of this kind of conversion (which happens almost
    >> every time "narrow" integer is used, not just with mixed types):
    >>
    >> - If the integer is "narrower" than int *and* if the range of
    >> int includes the entire range of the original type, the
    >> integer converts to (promotes to) int.

    >
    > Narrower than int, /or/ the same width as int (per n1256).


    Oh, pfui on yui. I didn't write narrower, I wrote "narrower."
    And I went so far as to write (and you went so far as to snip)

    >>> [...] I've simplified a bit by using "wide" and "narrow" and
    >>> waving my hands a little, and I've also ignored complex
    >>> arithmetic, but I hope it's enough to get you started.


    In my not-so-humble opinion, it's a disservice to the O.P. to try
    to drag all of the stuff about conversion ranks and so on into the
    discussion. He's been given the gist, he's been told there's more
    to it that he might want to investigate once his conceptual grasp
    is firmer (which it may be by now; the discussion was some three
    weeks ago), and that's quite enough for now, thanks.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jun 20, 2010
    #16
  17. mohangupta13

    Guest

    pete <> wrote:
    >
    > Have you noticed that the part of the standard called
    > "Sizes of integer types <limits.h>",
    > doesn't say anything about the sizes of integer types?


    It's a test to see if you're paying attention. :)

    Actually, it does say a number of things about the sizes of integer
    types, just indirectly.
    --
    Larry Jones

    I'm so disappointed. -- Calvin
     
    , Jun 20, 2010
    #17
  18. mohangupta13

    Tim Rentsch Guest

    Barry Schwarz <> writes:

    > On Sun, 20 Jun 2010 00:36:03 -0700, Tim Rentsch
    > <> wrote:
    >
    >>Barry Schwarz <> writes:
    >>
    >>> On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
    >>> <> wrote:
    >>>
    >>>>Eric Sosman <> writes:
    >>>>
    >>>>> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>>>>>[snip]
    >>>>>
    >>>>> There's also something called the "integer promotions," which
    >>>>> exist because many CPU's can perform arithmetic only on integers of
    >>>>> a few "widths." For example, a CPU that does all integer arithmetic
    >>>>> in registers may have no instructions for doing arithmetic on char
    >>>>> values: You fetch the char into a register (widening it as you go),
    >>>>> do the arithmetic in the wide register, and store (part of) the
    >>>>> result back in the char variable again. The integer promotions are
    >>>>> C's description of this kind of conversion (which happens almost
    >>>>> every time "narrow" integer is used, not just with mixed types):
    >>>>>
    >>>>> - If the integer is "narrower" than int *and* if the range of
    >>>>> int includes the entire range of the original type, the
    >>>>> integer converts to (promotes to) int.
    >>>>
    >>>>Narrower than int, /or/ the same width as int (per n1256).
    >>>
    >>> While the result is the same, the requirement to convert is specified
    >>> in terms of rank, not width (6.3.1.1-2).

    >>
    >>That's right, and the distinction is important, because
    >>different types can have the same width but still have
    >>different ranks. I used the "narrower" description
    >>because the posting I was responding to did; probably
    >>I should have put it in quotes like it was before.
    >>In any event, thank you for the clarification.

    >
    > Ignoring the differences between signed and unsigned integers, it is
    > required that a higher rank integer be able to represent all the
    > values of a lower rank integer. This is normally taken to mean the
    > higher rank integer is at least as big as the lower rank one. It
    > seems to me that the preceding statement must be true if one considers
    > only the value bits in the bytes the objects occupy and disregard any
    > padding bits.
    >
    > But sizeof includes the padding bits it its evaluation. So the
    > question becomes: Is it possible for a lower rank integer to have
    > enough padding bits so that it is actually larger than the higher rank
    > one? On a perverse system with 8-bit bytes, could INT_MAX be
    > 2147483647, SHRT_MAX be 32767, sizeof(int) be 4, and sizeof(short) be
    > 6 (16 value bits and 32 padding bits)?


    Yes. At least, I'm not aware of any Standard requirements
    that would preclude it. There aren't any restrictions on
    the relative sizes of different integer types (of a given
    signedness), except of course that they all must be >= 1,
    and the sizes must be big enough to hold all the value bits
    for their respective types.
     
    Tim Rentsch, Jun 20, 2010
    #18
  19. mohangupta13

    Tim Rentsch Guest

    Eric Sosman <> writes:

    > On 6/18/2010 2:13 PM, Tim Rentsch wrote:
    >> Eric Sosman<> writes:
    >>
    >>> On 6/1/2010 12:57 PM, mohangupta13 wrote:
    >>>> [snip]
    >>>
    >>> There's also something called the "integer promotions," which
    >>> exist because many CPU's can perform arithmetic only on integers of
    >>> a few "widths." For example, a CPU that does all integer arithmetic
    >>> in registers may have no instructions for doing arithmetic on char
    >>> values: You fetch the char into a register (widening it as you go),
    >>> do the arithmetic in the wide register, and store (part of) the
    >>> result back in the char variable again. The integer promotions are
    >>> C's description of this kind of conversion (which happens almost
    >>> every time "narrow" integer is used, not just with mixed types):
    >>>
    >>> - If the integer is "narrower" than int *and* if the range of
    >>> int includes the entire range of the original type, the
    >>> integer converts to (promotes to) int.

    >>
    >> Narrower than int, /or/ the same width as int (per n1256).

    >
    > Oh, pfui on yui. I didn't write narrower, I wrote "narrower."
    > And I went so far as to write (and you went so far as to snip)
    >
    >>>> [...] I've simplified a bit by using "wide" and "narrow" and
    >>>> waving my hands a little, and I've also ignored complex
    >>>> arithmetic, but I hope it's enough to get you started.


    Yes, and I should have written "narrower" rather than narrower,
    as I already stated in my response to Barry Schwarz.

    > In my not-so-humble opinion, it's a disservice to the O.P. to try
    > to drag all of the stuff about conversion ranks and so on into the
    > discussion.


    Usually I don't write comments just for the benefit of one person.
    Sometimes I do but usually I don't. If other people want to make
    different choices, that's okay with me, as long as they don't
    expect me to necessarily make the same choices.

    Also, the point of my comment was not about conversion ranks.
    It's about a significant difference in what "narrownesses"
    are relevant, not about any technical details of conversion ranks.

    > He's been given the gist, he's been told there's more
    > to it that he might want to investigate once his conceptual grasp
    > is firmer (which it may be by now; the discussion was some three
    > weeks ago), and that's quite enough for now, thanks.


    In my opinion, whether it's humble or it isn't, the distinction
    I pointed out is important to know about and also easy to
    explain in a not-overly-technical manner. Eg,

    If the integer is "narrower" than int (or the same "narrowness") ...

    If these four additional words had been present that would
    have covered the point I was addressing in my previous response.
    Glossing over minute technical details is no big deal.
    But glossing over significant conceptual differences is, IMO,
    a poor choice, even when explaining to beginners.
     
    Tim Rentsch, Jun 20, 2010
    #19
  20. Barry Schwarz <> writes:
    [...]
    > But sizeof includes the padding bits it its evaluation. So the
    > question becomes: Is it possible for a lower rank integer to have
    > enough padding bits so that it is actually larger than the higher rank
    > one? On a perverse system with 8-bit bytes, could INT_MAX be
    > 2147483647, SHRT_MAX be 32767, sizeof(int) be 4, and sizeof(short) be
    > 6 (16 value bits and 32 padding bits)?


    Certainly it's possible (in the sense that an implementation could have
    these characteristics while still being conforming). I'd be surprised
    if there were any real-world (non-DS9K) implementation with
    sizeof(short) > sizeof(int).

    I can almost think of a plausible reason for it, though. Imagine an
    architecture with a strong emphasis on floating-point performance.
    A C compiler might implement short using floating-point hardware,
    restricting the values to those that can be represented exactly;
    the exponent bits are padding bits. The floating-point type
    doesn't have enough mantissa bits for int, so int is implemented
    using integer hardware (or emulated in software); thus int doesn't
    need any padding bits.

    This could plausibly give you sizeof(short) == sizeof(int), but
    with different bounds. I'm not sure it could easily give you
    sizeof(short) > sizeof(int).

    --
    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, Jun 21, 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. Alexander Stippler
    Replies:
    6
    Views:
    434
    Rolf Magnus
    Oct 30, 2003
  2. Niels Dekker (no reply address)

    Usual arithmetic conversions + integral promotion for short?

    Niels Dekker (no reply address), May 19, 2004, in forum: C++
    Replies:
    10
    Views:
    1,948
    Niels Dekker (no reply address)
    May 22, 2004
  3. Fred Ma
    Replies:
    9
    Views:
    405
    Dave Thompson
    Feb 9, 2004
  4. Carsten Hansen

    Bit-fields and integral promotion

    Carsten Hansen, Jan 28, 2005, in forum: C Programming
    Replies:
    117
    Views:
    1,971
    Joe Wright
    Feb 8, 2005
  5. TTroy
    Replies:
    16
    Views:
    813
    Peter Nilsson
    Jan 31, 2005
Loading...

Share This Page