469,306 Members | 2,121 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,306 developers. It's quick & easy.

sizeof 'A'

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

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

Jul 10 '07 #1
58 6673
Nishu wrote:
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?
Because 'A' alone is an int.
Thanks,
Nishu
/**************************************/
#include<stdio.h>

int main(void)
{

const char ch = 'A';

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

return 0;
}

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

--
Pietro Cerutti

PGP Public Key:
http://gahr.ch/pgp
Jul 10 '07 #2
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
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?

Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.

Thanks,
Nishu
Jul 10 '07 #3
Nishu wrote:
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;
}

/*******************/
As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Why is this?

"Because that's the way it is..." :-)
Jul 10 '07 #4
On 10 Jul, 10:13, Nishu <naresh.at...@gmail.comwrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:Nishu wrote:
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?
Because 'A' alone is an int.

OK. What is the reason for considering it as int?
Because that's what the standard says it is. The standard calls 'A' an
integer character constant...
I think we use
single quotes to say that it is a char.
No. We use single quotes to denote an integer character constant.
Jul 10 '07 #5
Nishu <na**********@gmail.comwrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
Could you tell me why sizeof 'A' is taken as 4? Is it standard defined
or compiler specific?
Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.
For hysterical raisins, the type of a character constant is int. It's
one of the (IMO few) areas where C++ improves on C: in that language,
it's a char. But not, unfortunately, in C.

Richard
Jul 10 '07 #6
Nishu wrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
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?
Because 'A' alone is an int.
OK. What is the reason for considering it as int?
Actually it's considered an integer value, not necessarily an int. int
is just a particular integer type. So is short, long, long long etc.

The reason I suppose is a language design choice. By means of the
escape-sequence notation you can specify any arbitrary octal or
hexadecimal value, to encode character values that are not represented
in the source character set.
I think we use
single quotes to say that it is a char.
A sequence of one or more characters enclosed by single quotes is
regarded as a character constant, not a char. If it's a single
character, it's numerical value is the code for that character in the
machine's character set. Multi-character constants are treated in an
implementation defined manner.

Jul 10 '07 #7
On 10 Jul, 10:28, santosh <santosh....@gmail.comwrote:
Nishu wrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
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?
Because 'A' alone is an int.
OK. What is the reason for considering it as int?

Actually it's considered an integer value, not necessarily an int. int
is just a particular integer type. So is short, long, long long etc.
The spec (I'm looking at C89) states that "An integer character
constant has type _int_"...

Jul 10 '07 #8
On Jul 10, 1:37 am, mark_blue...@pobox.com wrote:
Because 'A' alone is an int.
OK. What is the reason for considering it as int?
Actually it's considered an integer value, not necessarily an int. int
is just a particular integer type. So is short, long, long long etc.

The spec (I'm looking at C89) states that "An integer character
constant has type _int_"...
OK. Thank you all.

-Nishu

Jul 10 '07 #9
mark_blue...@pobox.com wrote:
On 10 Jul, 10:28, santosh <santosh....@gmail.comwrote:
Nishu wrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
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?
Because 'A' alone is an int.
OK. What is the reason for considering it as int?
Actually it's considered an integer value, not necessarily an int. int
is just a particular integer type. So is short, long, long long etc.

The spec (I'm looking at C89) states that "An integer character
constant has type _int_"...
You're right. Thanks for the correction and apologies to the OP.

Jul 10 '07 #10
jacob navia wrote:
>
As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.
Just curious: With what is the int-ness of 'A' "inconsistent?"

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jul 10 '07 #11
Eric Sosman wrote:
jacob navia wrote:
>>
As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"
With it being a character of course.
Jul 10 '07 #12
jacob navia wrote:
Eric Sosman wrote:
>jacob navia wrote:
>>>
As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"

With it being a character of course.
It's consistent with getchar/putchar - I always thought that was the reason.
Jul 10 '07 #13
Richard Harnden wrote:
jacob navia wrote:
Eric Sosman wrote:
jacob navia wrote:

As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"
With it being a character of course.

It's consistent with getchar/putchar - I always thought that was the reason.
They were probably designed after the core language features were
decided upon.
getchar/putchar could very well return an int while character
constants could be of type char.

Jul 10 '07 #14
Richard Harnden <ri*****@oninit.comwrites:
jacob navia wrote:
Eric Sosman wrote:
jacob navia wrote:

As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"
With it being a character of course.

It's consistent with getchar/putchar - I always thought that was the reason.
Is it? putchar('\xFE') doesn't do the right thing if char is signed.

Yours,

--
Jean-Marc
Jul 10 '07 #15
jacob navia wrote On 07/10/07 08:40,:
Eric Sosman wrote:
>>jacob navia wrote:
>>>As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"


With it being a character of course.
... but since it *isn't* a character, you might just
as well say its int-ness is inconsistent with it being
a struct tm. The int-ness of 'A' may be surprising[*],
but I can't think of any convention or practice elsewhere
in the language that establishes a pattern with which
it could be inconsistent.
[*] Or maybe not, when you consider the usual
arithmetic conversions (6.3.1.8). With the exception
of sizeof, every operator[**] you could apply to a
char-type 'A' would promote its value to int or unsigned
int anyhow.

[**] If I've overlooked something, I'm confident
someone will remind me.

--
Er*********@sun.com
Jul 10 '07 #16
On Tue, 10 Jul 2007 14:40:52 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Eric Sosman wrote:
>jacob navia wrote:
>>>
As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"

With it being a character of course.
Where does it say that characters are the same size as chars?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Jul 10 '07 #17
Mark McIntyre <ma**********@spamcop.netwrites:
On Tue, 10 Jul 2007 14:40:52 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Eric Sosman wrote:
>>jacob navia wrote:

As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"

With it being a character of course.

Where does it say that characters are the same size as chars?
Yeah, how could *anyone* get confused by *that*?!?!?!?

<rolls eyes>

It was a dubious decision, for whatever reason, to default a character
constant to an int and not a char. Someone better versed in the history
gave a better point of view elsewhere in the thread.

Jul 10 '07 #18
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Nishu <na**********@gmail.comwrote:
>On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
Could you tell me why sizeof 'A' is taken as 4? Is it standard defined
or compiler specific?

Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.

For hysterical raisins, the type of a character constant is int. It's
one of the (IMO few) areas where C++ improves on C: in that language,
it's a char. But not, unfortunately, in C.
It makes very little difference in C; expressions of type char are
almost always promoted to int anyway. Applying sizeof to a character
constant is nearly the only case where the different shows up.

<OT>It matters more in C++ because of overloading; func('A') and
func(65) might call two different functions.</OT>

This is question 8.9 in the comp.lang.c FAQ.

--
Keith Thompson (The_Other_Keith) 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"
Jul 10 '07 #19
Eric Sosman <Eric.Sos...@sun.comwrote:
jacob navia wrote On 07/10/07 08:40,:
Eric Sosman wrote:
jacob navia wrote:
As Pietro said, 'A' is considered an int in C,
not a character. This is one of the many
inconsistencies of the language that you must
learn by heart.
>
Just curious: With what is the int-ness
of 'A' "inconsistent?"
With it being a character of course.
... but since it *isn't* a character,
'A' could not possibly be thought of as character?!

Even if you 'know better', I can't believe the obviousness
of the expectation eludes you.

Note that C++ didn't make 'A' a char to support overloading.
That is incidental. C++ made 'A' a char because it's common
sense to think of and _use_ 'A' as a character. The
situation is no different in C.
you might just as well say its int-ness is inconsistent
with it being a struct tm.
If it had two distinct types simultaniously, I would say it
was inconsistent, yes.
The int-ness of 'A' may be surprising[*],
It is surprising.
but I can't think of any convention or practice elsewhere
in the language that establishes a pattern with which
it could be inconsistent.
Can you think of any convention or practice elsewhere in
the language that would established a pattern with which
'A' being a character would be inconsistent?
[*] Or maybe not, when you consider the usual
arithmetic conversions (6.3.1.8).
And why would making 'A' a character be inconsistent with
the usual arithmetic conversions? C++ programmers are no
more hampered in writing (*p - '0') than C programmers.
With the exception of sizeof, every operator[**] you
could apply to a char-type 'A' would promote its value
to int or unsigned int anyhow.
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?
[**] If I've overlooked something, I'm confident
someone will remind me.
Here's a question for you: If it's so obvious why 'A'
should be an int, why then does '\xfe' have no less
than 4 distinct possible values, depending on the
implementation?

C was designed for a purpose. Being a useful and
intuitive language for beginners wasn't one of them.
;-)

--
Peter

Jul 11 '07 #20
Peter Nilsson <ai***@acay.com.auwrites:
Eric Sosman <Eric.Sos...@sun.comwrote:
[...]
Note that C++ didn't make 'A' a char to support overloading.
That is incidental. C++ made 'A' a char because it's common
sense to think of and _use_ 'A' as a character. The
situation is no different in C.
<OT>
According to the C++ standard, C++ made character constants type char
precisely because of overloading. See Annex C of the 1998 C++
standard:

Change: Type of character literal is changed from int to char
Rationale: This is needed for improved overloaded function
argument type matching.
</OT>
>The int-ness of 'A' may be surprising[*],

It is surprising.
Agreed (though I got over the surprise some time ago).
>but I can't think of any convention or practice elsewhere
in the language that establishes a pattern with which
it could be inconsistent.

Can you think of any convention or practice elsewhere in
the language that would established a pattern with which
'A' being a character would be inconsistent?
Yes. 'A' is a constant. No other constants are of any integer type
smaller than int. For example, the macro CHAR_MAX typically expands
to either 127 or 255; both of these are constants of type int. The
language provides suffixes for integer constants that make them of
type long, unsigned int, unsigned long, and so forth, but there are no
such suffixes for char, unsigned char, signed char, short, or unsigned
short.

All C expressions of integer type are of type int, unsigned int, or
something larger. Even the name of an object of type char is promoted
to int (or, very rarely, to unsigned int) unless it's the operand of
"&" or "sizeof". Why should character constants be a special case?

The only case where it makes any difference is when a character
constant is the operand of sizeof. How often do you really apply
sizeof to a character constant in real code (unless you're trying to
determine whether you're using a C or C++ compiler)?

--
Keith Thompson (The_Other_Keith) 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"
Jul 11 '07 #21
Keith Thompson said:

<snip>
How often do you really apply
sizeof to a character constant in real code (unless you're trying to
determine whether you're using a C or C++ compiler)?
And, quite possibly, failing, since sizeof 'A' can certainly be 1, even
though 'A' is an int.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 11 '07 #22
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?

Yes, it's implementation-defined. And yes, because of
its implementation-definedness it is (justifiably) denigrated.
But to deny its existence -- and occasional usefulness -- is
to deny the history of C. (Ritchie's writings on the descent
of C from B and the evanescent NB make illuminating reading.)

True, there's precedent for the value of a constant to
determine its type, over and above its lexical appearance:
42 is an int, but 42424242424242424242424242424242424 quite
likely isn't. But that's not really a "pre"cedent, since
it's a rule that was invented long after C began, a rule
that describes rather than prescribes.

Other than offering newbies a surprise -- and let's face
it, there are *many* things about C that surprise newbies --
can you think of even one deleterious consequence of 'A' being
an int?

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jul 11 '07 #23
Keith Thompson wrote:
All C expressions of integer type are of type int, unsigned int, or
something larger. Even the name of an object of type char is promoted
to int (or, very rarely, to unsigned int) unless it's the operand of
"&" or "sizeof".
There's no promotion when the left and right operands
of the assignment operator are of type char.

There's no promotion when an expression of type char
is added to a pointer.

The logical operators don't cause the promotion
of their operands,
and neither does the comma operator.

It's not like for an array name.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
char a = 0;
char array[7] = "";

printf("sizeof (a , a) is %u\n", (unsigned)sizeof (a , a));
printf("sizeof ( a) is %u\n\n", (unsigned)sizeof ( a));

printf("sizeof (array , array) is %u\n",
(unsigned)sizeof (array , array));
printf("sizeof ( array) is %u\n",
(unsigned)sizeof ( array));
return 0;
}

/* END new.c */
--
pete
Jul 11 '07 #24
Eric Sosman <Er*********@sun.comwrote:
jacob navia wrote On 07/10/07 08:40,:
Eric Sosman wrote:
>jacob navia wrote:

As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"
With it being a character of course.

... but since it *isn't* a character,
Yes, it is. 'A' is a character constant. It is not a character type.
That's the inconsistency: character constants don't have character type,
but type int.

Richard
Jul 11 '07 #25
Eric Sosman <es*****@ieee-dot-org.invalidwrote:
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?
Never mind type, what _value_ should it have? IMO, none. Character
constants should be limited to a single member of the execution
character set.

Richard
Jul 11 '07 #26
Keith Thompson <ks***@mib.orgwrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Nishu <na**********@gmail.comwrote:
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Because 'A' alone is an int.

OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.
For hysterical raisins, the type of a character constant is int. It's
one of the (IMO few) areas where C++ improves on C: in that language,
it's a char. But not, unfortunately, in C.

It makes very little difference in C; expressions of type char are
almost always promoted to int anyway. Applying sizeof to a character
constant is nearly the only case where the different shows up.
Oh, I know that; but it irks me for philosophical reasons.

Richard
Jul 11 '07 #27
On Jul 11, 10:04 am, pete <pfil...@mindspring.comwrote:
Keith Thompson wrote:
All C expressions of integer type are of type int, unsigned int, or
something larger. Even the name of an object of type char is promoted
to int (or, very rarely, to unsigned int) unless it's the operand of
"&" or "sizeof".

There's no promotion when the left and right operands
of the assignment operator are of type char.

There's no promotion when an expression of type char
is added to a pointer.

The logical operators don't cause the promotion
of their operands,
and neither does the comma operator.
This appplies to a cast expression and also in the case, when it is a
primary expression.

That is:

unsigned char c='A';
(unsigned)c;
c;
(c);
/*In the last 3 expression statements, there need to be no promotion,
although having promotion doesn't affect the behavior of the code.*/

In general, integer promotion occurs only when the operand having rank
less that int, is an operand of an arithmetic operator.
>
It's not like for an array name.
What are you trying to prove with array names?

Array names are always converted into an rvalue equal to the pointer
to the first element except when it is an operand of sizeof or &.

Note that array names are NOT promoted. The pointer value you get with
array name is analogous to the char value you get when you have an
identifier of type char, in rvalue context. Promotion is what, that
subsequently occurs, when char operand is an operand of an arithmetic
operator (need not occur otherwise).

Note that,for array names there is no "promotion" defined by the
standards. If you are refferring to evaluation of array name as
pointer, then that is incorrect terminology!
>
/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
char a = 0;
char array[7] = "";

printf("sizeof (a , a) is %u\n", (unsigned)sizeof (a , a));
printf("sizeof ( a) is %u\n\n", (unsigned)sizeof ( a));

printf("sizeof (array , array) is %u\n",
(unsigned)sizeof (array , array));
printf("sizeof ( array) is %u\n",
(unsigned)sizeof ( array));
return 0;

}

/* END new.c */

Jul 11 '07 #28
pete <pf*****@mindspring.comwrites:
Keith Thompson wrote:
>All C expressions of integer type are of type int, unsigned int, or
something larger. Even the name of an object of type char is promoted
to int (or, very rarely, to unsigned int) unless it's the operand of
"&" or "sizeof".

There's no promotion when the left and right operands
of the assignment operator are of type char.

There's no promotion when an expression of type char
is added to a pointer.

The logical operators don't cause the promotion
of their operands,
and neither does the comma operator.
[snip]

Ok, you're right. 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;
}

The output I get (on a system with sizeof(int)==4) is:

sizeof c = 1
sizeof (c, c) = 1
sizeof (c + 0) = 4

It's still the case that it hardly ever matters whether character
constants are of type int or of type char.

--
Keith Thompson (The_Other_Keith) 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"
Jul 11 '07 #29
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
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?
Well, a noob for sure would think thats how you define a character
string.

'AB' is not "a character" in any sense.
>
Yes, it's implementation-defined. And yes, because of
its implementation-definedness it is (justifiably) denigrated.
But to deny its existence -- and occasional usefulness -- is
to deny the history of C. (Ritchie's writings on the descent
of C from B and the evanescent NB make illuminating reading.)

True, there's precedent for the value of a constant to
determine its type, over and above its lexical appearance:
42 is an int, but 42424242424242424242424242424242424 quite
likely isn't. But that's not really a "pre"cedent, since
it's a rule that was invented long after C began, a rule
that describes rather than prescribes.

Other than offering newbies a surprise -- and let's face
it, there are *many* things about C that surprise newbies --
can you think of even one deleterious consequence of 'A' being
an int?
--
Jul 11 '07 #30
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Eric Sosman <Er*********@sun.comwrote:
>jacob navia wrote On 07/10/07 08:40,:
Eric Sosman wrote:

jacob navia wrote:

As Pietro said, 'A' is considered an int in C, not
a character. This is one of the many inconsistencies of the
language that you must learn by heart.

Just curious: With what is the int-ness of 'A' "inconsistent?"

With it being a character of course.

... but since it *isn't* a character,

Yes, it is. 'A' is a character constant. It is not a character type.
That's the inconsistency: character constants don't have character type,
but type int.

Richard
Which is the crux of the issue. I find it hard to believe that anyone,
even in this group, would argue that a character constant has type int
is a good thing.
Jul 11 '07 #31
Richard wrote:
[...]
Which is the crux of the issue. I find it hard to believe that anyone,
even in this group, would argue that a character constant has type int
is a good thing.
... but is it in any sense "bad?" Seems to me this
entire thread is a tempest in a type-pot.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jul 11 '07 #32
Eric Sosman <es*****@ieee-dot-org.invalidwrites:
Richard wrote:
>[...]
Which is the crux of the issue. I find it hard to believe that anyone,
even in this group, would argue that a character constant has type int
is a good thing.

... but is it in any sense "bad?" Seems to me this
entire thread is a tempest in a type-pot.
Yes. It promotes a billion posts of

'A' is not type char ....

OK, its not end of the world, but ...
Jul 11 '07 #33
Eric Sosman <es*****@ieee-dot-org.invalidwrote:
Richard wrote:
[...]
Which is the crux of the issue. I find it hard to believe that anyone,
even in this group, would argue that a character constant has type int
is a good thing.

... but is it in any sense "bad?"
Since it violates the principle of least surprise, yes. Not _very_ bad,
I'll grant you, but still slightly bad. Let's call it naughty.

Richard
Jul 11 '07 #34
"Nishu" <na**********@gmail.comwrote in message
news:11**********************@o11g2000prd.googlegr oups.com...
On Jul 10, 1:07 am, Pietro Cerutti wrote:
>Nishu wrote:
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?

Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.
Single quotes in this context actually specify a type conversion, same as
ORD() did in old versions of basic.

The issue isn't the final data type ... the issue is how one gets from 'A'
to the ASCII value of 'A'.

In other languages:

i = ORD("A");

In C:

i = 'A';

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)
Jul 11 '07 #35
David T. Ashley wrote:
"Nishu" <na**********@gmail.comwrote in message
news:11**********************@o11g2000prd.googlegr oups.com...
On Jul 10, 1:07 am, Pietro Cerutti wrote:
Nishu wrote:
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?

Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.

Single quotes in this context actually specify a type conversion, same as
ORD() did in old versions of basic.

The issue isn't the final data type ... the issue is how one gets from 'A'
to the ASCII value of 'A'.
To the value of 'A' in the machine execution character set, which
needn't be ASCII.

Jul 11 '07 #36
Richard Bos wrote, On 11/07/07 15:30:
Eric Sosman <es*****@ieee-dot-org.invalidwrote:
>Richard wrote:
>>[...]
Which is the crux of the issue. I find it hard to believe that anyone,
even in this group, would argue that a character constant has type int
is a good thing.
... but is it in any sense "bad?"

Since it violates the principle of least surprise, yes. Not _very_ bad,
I'll grant you, but still slightly bad. Let's call it naughty.
I agree with Richard Bos here. I think the language would be cleaner if
character constants were of type char, with the obvious corollary that
multi-character constants were invalid (required a diagnostic). However,
the language has worse things in it than that.
--
Flash Gordon
Jul 11 '07 #37
CryptiqueGuy wrote:
>
On Jul 11, 10:04 am, pete <pfil...@mindspring.comwrote:
Keith Thompson wrote:
All C expressions of integer type are of type int,
unsigned int, or something larger.
Even the name of an object of type char is promoted
to int (or, very rarely, to unsigned int)
unless it's the operand of "&" or "sizeof".
It's not like for an array name.

What are you trying to prove with array names?
The way that Keith Thompson used & and sizeof as exceptions,
to describe when the integer promotions take place,
reminded me of how the standard describes
the explicit conversions of expressions of array type,
by noting the exceptions instead of stating the cases.

The standard states each case
where expressions of low ranking types
are subject to the integer promotions.

The standard describes where the explicit conversions
of expressions of array type take place
by listing the few exceptions where they don't occur.

N869
6.3.2.1 Lvalues and function designators
[#3] Except when it is the operand of the sizeof operator or
the unary & operator, or is a string literal used to
initialize an array, an expression that has type ``array of
type'' is converted to an expression with type ``pointer to
type'' that points to the initial element of the array
object and is not an lvalue.

--
pete
Jul 11 '07 #38
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.

--
pete
Jul 11 '07 #39
"David T. Ashley" <dt*@e3ft.comwrites:
"Nishu" <na**********@gmail.comwrote in message
news:11**********************@o11g2000prd.googlegr oups.com...
>On Jul 10, 1:07 am, Pietro Cerutti wrote:
>>Nishu wrote:
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?

Because 'A' alone is an int.
OK. What is the reason for considering it as int? I think we use
single quotes to say that it is a char.

Single quotes in this context actually specify a type conversion, same as
ORD() did in old versions of basic.
No, the single quotes specify a charater constant, which is inherently
of type int.

--
Keith Thompson (The_Other_Keith) 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"
Jul 11 '07 #40
pete <pf*****@mindspring.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_Keith) 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"
Jul 11 '07 #41
On Jul 11, 11:51 pm, Richard <rgr...@gmail.comwrote:
'AB' is not "a character" in any sense.
Except for the sense covered by section
6.4.4.4 of the C standard.

Jul 11 '07 #42
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
Jul 12 '07 #43
pete <pf*****@mindspring.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
Jul 12 '07 #44
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
Jul 12 '07 #45
Ben Pfaff wrote:
>
pete <pf*****@mindspring.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
Jul 12 '07 #46
pete wrote:
>
Ben Pfaff wrote:

pete <pf*****@mindspring.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
Jul 12 '07 #47
pete <pf*****@mindspring.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.
Jul 12 '07 #48
Eric Sosman <esos...@ieee-dot-org.invalidwrote:
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

Jul 12 '07 #49
Peter Nilsson wrote On 07/11/07 22:06,:
Eric Sosman <esos...@ieee-dot-org.invalidwrote:
>>-- 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
Jul 12 '07 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Sunil Menon | last post: by
19 posts views Thread by Martin Pohlack | last post: by
9 posts views Thread by M Welinder | last post: by
7 posts views Thread by dam_fool_2003 | last post: by
42 posts views Thread by Christopher C. Stacy | last post: by
8 posts views Thread by junky_fellow | last post: by
90 posts views Thread by pnreddy1976 | last post: by
32 posts views Thread by Abhishek Srivastava | last post: by
5 posts views Thread by Francois Grieu | last post: by
1 post views Thread by CARIGAR | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.