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

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

 

[Pietro Cerutti]

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.

 

[Nishu]

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

 

[jacob navia]

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

 

[mark_bluemel]

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.

 

[Richard Bos]

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

 

[santosh]

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.

 

[mark_bluemel]

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

 

[Nishu]

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

OK. Thank you all.

-Nishu

 

[santosh]

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.

 

[Eric Sosman]

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

 

[jacob navia]

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

With it being a character of course.

 

[Richard Harnden]

With it being a character of course.

It's consistent with getchar/putchar - I always thought that was the reason.

 

[santosh]

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.

 

[Jean-Marc Bourguet]

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,

 

[Eric Sosman]

jacob navia wrote On 07/10/07 08:40,:

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.

 

[Mark McIntyre]

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

 

[Richard]

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.

 

[Keith Thompson]

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.

 

[Peter Nilsson]

jacob navia wrote On 07/10/07 08:40,:
... 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.
;-)