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

On Jun 1, 9:57=A0am, mohangupta13 <mohangupt...@gmail.com> 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 ...
> =A0kindly 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=3D
> 10010111---> 1111111110010111 (in int)...
>
> 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???
>
> 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/

On Jun 1, 10:17=A0pm, kathir <kathir...@gmail.com> wrote:
> On Jun 1, 9:57=A0am, mohangupta13 <mohangupt...@gmail.com> 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 ...
> > =A0kindly 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=3D
> > 10010111---> 1111111110010111 (in int)...
>
> > 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???
>
> > 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/

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.

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

kathir <kathircpp@gmail.com> wrote:

> On Jun 1, 9:57=A0am, mohangupta13 <mohangupt...@gmail.com> 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

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
esosman@ieee-dot-org.invalid

mohangupta13 <mohangupta13@gmail.com> 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

On 6/1/2010 4:09 PM, lawrence.jones@siemens.com wrote:
> mohangupta13<mohangupta13@gmail.com>  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
esosman@ieee-dot-org.invalid

On Tue, 1 Jun 2010 09:57:01 -0700 (PDT), mohangupta13
<mohangupta13@gmail.com> 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

On Jun 2, 8:48=A0am, Barry Schwarz <schwa...@dqel.com> wrote:
> On Tue, 1 Jun 2010 09:57:01 -0700 (PDT), mohangupta13
>
> <mohangupt...@gmail.com> 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. =A0If 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=3D
> >10010111---> 1111111110010111 (in int)...
>
> You are discussing how a value is represented. =A0That is not the issue.
> When a char is promoted to int, the value is unchanged. =A0If the
> hardware uses a signed magnitude representation, then the sign bit is
> not extended. =A0
>
> You really shouldn't care unless you are writing code that depends on
> a particular representation. =A0If 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=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???
>
> 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. =A0
>
> The decision is usually based on how characters are represented.
> Windows systems have char equivalent to signed char. =A0IBM 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

Eric Sosman <esosman@ieee-dot-org.invalid> 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).

On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Eric Sosman <esosman@ieee-dot-org.invalid> 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 <schwarzb@dqel.com> writes:

> On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>>Eric Sosman <esosman@ieee-dot-org.invalid> 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 wrote:
> 
> Barry Schwarz <schwarzb@dqel.com> writes:

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

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?

-- 
pete

On Sun, 20 Jun 2010 00:36:03 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:

>Barry Schwarz <schwarzb@dqel.com> writes:
>
>> On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
>>
>>>Eric Sosman <esosman@ieee-dot-org.invalid> 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

On 6/18/2010 2:13 PM, Tim Rentsch wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  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
esosman@ieee-dot-org.invalid

pete <pfiland@mindspring.com> 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

Barry Schwarz <schwarzb@dqel.com> writes:

> On Sun, 20 Jun 2010 00:36:03 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>>Barry Schwarz <schwarzb@dqel.com> writes:
>>
>>> On Fri, 18 Jun 2010 11:13:08 -0700, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>>>
>>>>Eric Sosman <esosman@ieee-dot-org.invalid> 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.

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 6/18/2010 2:13 PM, Tim Rentsch wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  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.

Barry Schwarz <schwarzb@dqel.com> 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) kst-u@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"

On 1 June, 18:17, kathir <kathir...@gmail.com> wrote:
> On Jun 1, 9:57=A0am, mohangupta13 <mohangupt...@gmail.com> wrote:

<snip>

> > 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

no. plain "char" must have the same representation as one of the types
"signed char" or "unsignd char". It is implementaion defined which.
Soem implementaions even allow you to select it.

> > ..but some
> > threads say its implementation define ...confusion here???

the implementaion defined people are correct you are mistaken.


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

you are giving information about a particular implementation (I'd
guess a Windows system as it usually Windows people that make this
mistake). Other implementations do it some other way. Some don't allow
you modify it at all.


--
We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
               (Using and Porting GNU CC)

On 6/20/2010 5:37 PM, Tim Rentsch wrote:
> [... in re imprecision of "narrower," in quotes ...]
> 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.

     "Glossing over?"  No, make that "?!!!"  I said, right out,
that my use of words like "narrow" was imprecise and that I was
doing some hand-waving; that's "glossing over?"  I wrote

 >> [...] 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.)

.... and you call this "glossing over?"  Sheesh.

     Once again, pfui on yui.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 6/20/2010 5:37 PM, Tim Rentsch wrote:
>> [... in re imprecision of "narrower," in quotes ...]
>> 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.
>
>     "Glossing over?"  No, make that "?!!!"  I said, right out,
> that my use of words like "narrow" was imprecise and that I was
> doing some hand-waving; that's "glossing over?"  I wrote
>
>>> [...] 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.)
>
> ... and you call this "glossing over?"  Sheesh.

I call it glossing over because a salient aspect is not
directly stated.  Not because it isn't brought up in a
reference, not because it isn't explained in enough detail,
but because it isn't stated directly, even allowing the
statement to be fuzzy.

>     Once again, pfui on yui.

It seems like this is just a difference of opinion about
which details are important to include and which can
reasonably be left out.  Why does that difference of
opinion provoke such a strong reaction?

lawrence.jones@siemens.com writes:

> pete <pfiland@mindspring.com> 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.

In the case of unsigned char I'd say it does so directly.

-- 
Ben.

Ben Bacarisse wrote:
> 
> lawrence.jones@siemens.com writes:
> 
> > pete <pfiland@mindspring.com> 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?

> In the case of unsigned char I'd say it does so directly.

This section of the C99 standard:
   7.10 Sizes of integer types <limits.h>
has neither the word "size" nor the word "byte", anywhere in it.

-- 
pete

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> lawrence.jones@siemens.com writes:
>> 
>> > pete <pfiland@mindspring.com> 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?
>
>> In the case of unsigned char I'd say it does so directly.
>
> This section of the C99 standard:
>    7.10 Sizes of integer types <limits.h>
> has neither the word "size" nor the word "byte", anywhere in it.

You did not, originally, reference 7.10, you just gave the name of the
section.  7.10 is two paragraphs and does all its work by referring to
the other section with that name: "5.2.4.2.1 Sizes of integer types
<limits.h>".

Was your original remark simply about 7.10?  If so, I don't really see
the point you are making.  The fact that 5.2.4.2.1 does not say much,
directly, about the sizes of integer types is surely more interesting.

-- 
Ben.

Ben Bacarisse wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> >>
> >> lawrence.jones@siemens.com writes:
> >>
> >> > pete <pfiland@mindspring.com> 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?
> >
> >> In the case of unsigned char I'd say it does so directly.
> >
> > This section of the C99 standard:
> >    7.10 Sizes of integer types <limits.h>
> > has neither the word "size" nor the word "byte", anywhere in it.
> 
> You did not, originally, reference 7.10, you just gave the name of the
> section.  7.10 is two paragraphs and does all its work by referring to
> the other section with that name: "5.2.4.2.1 Sizes of integer types
> <limits.h>".
> 
> Was your original remark simply about 7.10?

No. It was about 5.2.4.2.1, 
but I forgot what the chapter and verse was.
When I searched the standard for the same phrase
so that I could post the C&V, I didn't know that there
were two places where it was, so when the search found 
  7.10 Sizes of integer types <limits.h>
I thought it was the same place.

> If so, I don't really see
> the point you are making.  The fact that 5.2.4.2.1 does not say much,
> directly, about the sizes of integer types is surely more interesting.


-- 
pete

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
>> 
>> pete <pfiland@mindspring.com> writes:
>> 
>> > Ben Bacarisse wrote:
>> >>
>> >> lawrence.jones@siemens.com writes:
>> >>
>> >> > pete <pfiland@mindspring.com> 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?
>> >
>> >> In the case of unsigned char I'd say it does so directly.
>> >
>> > This section of the C99 standard:
>> >    7.10 Sizes of integer types <limits.h>
>> > has neither the word "size" nor the word "byte", anywhere in it.
>> 
>> You did not, originally, reference 7.10, you just gave the name of the
>> section.  7.10 is two paragraphs and does all its work by referring to
>> the other section with that name: "5.2.4.2.1 Sizes of integer types
>> <limits.h>".
>> 
>> Was your original remark simply about 7.10?
>
> No. It was about 5.2.4.2.1, 
> but I forgot what the chapter and verse was.
> When I searched the standard for the same phrase
> so that I could post the C&V, I didn't know that there
> were two places where it was, so when the search found 
>   7.10 Sizes of integer types <limits.h>
> I thought it was the same place.

Yes, it's confusing and 5.2.4.2.1 does include the word "byte"!

<snip>
-- 
Ben.