sizeof 'A'

[Nishu]

Hi All,
When I run the below program in MSVC, I get the output as
1
4
Could you tell me why sizeof 'A' is taken as 4? Is it standard defined
or compiler specific?
Thanks,
Nishu
/*************** *************** ********/
#include<stdio. h>

int main(void)
{

const char ch = 'A';

printf("%d\n", sizeof ch);
printf("%d\n", sizeof 'A');

return 0;
}

/*************** ****/

[Keith Thompson]

pete <pf*****@mindsp ring.comwrites:

Keith Thompson wrote:

>Here's another good illustration of your point:

#include <stdio.h>
int main(void)
{
char c;
printf("sizeof c = %d\n", (int)sizeof c);
printf("sizeof (c, c) = %d\n", (int)sizeof (c, c));
printf("sizeof (c + 0) = %d\n", (int)sizeof (c + 0));
return 0;
}

I think that (c + c) would be a better example of integer promotions,
than (c + 0) is,
because even if there were no such thing as "integer promotions",
the "usual arithmetic conversions" would still operate to make
(c + 0) be an expression of type int.

Agreed.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Old Wolf]

On Jul 11, 11:51 pm, Richard <rgr...@gmail.c omwrote:

'AB' is not "a character" in any sense.

Except for the sense covered by section
6.4.4.4 of the C standard.

[pete]

CryptiqueGuy wrote:

In general, integer promotion occurs only when the operand having rank
less that int, is an operand of an arithmetic operator.

Shift operators do integer promotions.

--
pete

[Ben Pfaff]

pete <pf*****@mindsp ring.comwrites:

CryptiqueGuy wrote:

>In general, integer promotion occurs only when the operand having rank
less that int, is an operand of an arithmetic operator.

Shift operators do integer promotions.

Isn't a shift operator an arithmetic operator? I am honestly
curious about the distinction you are making here, which is not
clear to me.
--
"I should killfile you where you stand, worthless human." --Kaz

[pete]

pete wrote:

>
CryptiqueGuy wrote:

In general, integer promotion occurs only when
the operand having rank
less that int, is an operand of an arithmetic operator.

Shift operators do integer promotions.

Actually, there's a whole bunch of operators,
besides the arithmetic ones,
that cause the usual arithmetic conversions.
The usual arithmetic conversions
include the integer promotions.

--
pete

[pete]

Ben Pfaff wrote:

>
pete <pf*****@mindsp ring.comwrites:

CryptiqueGuy wrote:

In general, integer promotion occurs only when the operand having rank
less that int, is an operand of an arithmetic operator.

Shift operators do integer promotions.

Isn't a shift operator an arithmetic operator? I am honestly
curious about the distinction you are making here, which is not
clear to me.

I consider it to be a bitwise operator.
Do you consider bitwise operators to arithmetic operators?

--
pete

[pete]

pete wrote:

>
Ben Pfaff wrote:

pete <pf*****@mindsp ring.comwrites:

CryptiqueGuy wrote:
>In general, integer promotion occurs only when the operand having rank
>less that int, is an operand of an arithmetic operator.
>
Shift operators do integer promotions.

Isn't a shift operator an arithmetic operator? I am honestly
curious about the distinction you are making here, which is not
clear to me.

I consider it to be a bitwise operator.
Do you consider bitwise operators to arithmetic operators?

K&R2 has arithmetic operators in section 2.5
and bitwise operators in section 2.9.

The index of the C99 standard, groups shift operators
and bitwise operators under the entry for "arithmetic operators",
but the C90 standard index, doesn't.

--
pete

[Ben Pfaff]

pete <pf*****@mindsp ring.comwrites:

Ben Pfaff wrote:

>Isn't a shift operator an arithmetic operator? I am honestly
curious about the distinction you are making here, which is not
clear to me.

I consider it to be a bitwise operator.
Do you consider bitwise operators to arithmetic operators?

Ah, I understand what you are saying now. I am not sure whether
I agree or disagree. After all, I most often use shift operators
to do arithmetic, and their behavior is defined arithmetically.
But I definitely understand their operation in terms of their
effect on bits, too. I think that it may be a gray area.
Ultimately it is not too important, I guess.

C99's index has bitwise operators, shift operators, and other
kinds of operators as subcategories under "arithmetic
operators".
--
In personal news, I passed my PhD oral exam this afternoon. So I
will be receiving my PhD pretty soon, probably by the end of
September, as soon as my thesis is accepted.

[Peter Nilsson]

Eric Sosman <[e-mail] e:

Peter Nilsson wrote:

[...]
So let me turn that back at you. If it's going to happen
anyhow, again I ask, why would making 'A' a char cause
any harm?

What type should 'AB' have?

I think char, but my opinion is irrelevant. [I also think
C should have a separate byte type, and that char should
be implementation defined, only come in the plain varienty,
and be unsigned (like size_t); but that's not likely to
get through the Committee, whether the concept has merit
or not.]

<snip>

Other than offering newbies a surprise -- and
let's face it, there are *many* things about C that
surprise newbies

Plenty of experienced programmers examining C for the
first time are surprised by the fact too. These days,
more and more programmers are encountering C++ before
the encounter C.

-- can you think of even one deleterious consequence of
'A' being an int?

I think '\xfe' having 4 different values is more of a
concern to me that it's type. Happy to agree that 'A'
being an int isn't really an issue for C programmers...
presently... 'user' defined type generic functions may
change that.

But the issue that sparked the sub thread was your
argument that character constants not having a character
type should not come as a surprise (to anyone).

Even if it's no more significant than the so-called
birthday paradox, it's still a surprise to many people.

--
Peter

[Eric Sosman]

Peter Nilsson wrote On 07/11/07 22:06,:

Eric Sosman <[e-mail] e:

>>-- can you think of even one deleterious consequence of
'A' being an int?

I think '\xfe' having 4 different values is more of a
concern to me that it's type. [...]

'\xfe' is always 254 on systems where the behavior is
defined, that is, on systems where CHAR_MAX >= 254. On
other systems the behavior is undefined and there's no
reason to restrict the outcome to just three other values.
Could be any value at all, or nasal demons.

Argument for undefinedness:

6.4.4.4p6 says "[...] The numerical value of the
hexadecimal integer so formed specifies the value of
the desired character or wide character." The specified
value is therefore 254.

6.4.4.4p10 says "[...] If an integer character constant
contains a single character or escape sequence, its value is
the one that results when an object with type char whose
value is that of the single character or escape sequence is
converted to type int." Hence, the value of '\xfe' is the
result of converting a char object with value 254 to int.

On a system where CHAR_MAX < 254 no char object can
have the value 254, so 6.4.4.4p10 does not specify the
value of '\xfe' on those systems.

4p2 says "[...] Undefined behavior is otherwise
indicated [...] by the omission of any explicit definition
of behavior. There is no difference in emphasis among these
three; they all describe ``behavior that is undefined.''"
Since the derivation of an int value from '\xfe' is not
explicitly defined when CHAR_MAX < 254, the behavior is
undefined.

Observation: The int-ness of character constants is not
to blame for this situation. If they were of type char and
the conversion language were deleted from 6.4.4.4p10, you'd
still be stuck with the fact that no char can have a value
greater than CHAR_MAX. The value of '\xfe' (if it has one)
is not germane to the debate over character constants' types.

--
Er*********@sun .com