o/p problem

[Mark McIntyre]

@Pieter
thanx for the help offered...

firstly, can you please read thislease quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.
<

but i still do think that there must be some logic as to y the c
compiler behaves in this fashion...

Secondly,. please do not use abbreviations in posts, such as y for
why, d for the. Your posts will be easier to read if you avoid
unnecessary abbreviations.

if someone knows d logic, just let me know ...

There *is* no single logic, it depends on your compiler, operating
system, character set (anyone tried it on a non-ISO charset?), etc
etc.

 

[Mark McIntyre]

By the way it seems that you are the guardian of the 'Usenet messaging
standards'

No, he's just a responsible citizen.

Because I have seen similar comments from you on many other posts.

And yet you still don't follow his advice. Strange...

Have you ever posted a message that has proved helpful to someone ? )

He's already posted advice that will be helpful to you. For instance
if you continue to ignore the comment about google posting, people
will start ignoring your posts entirely.

 

[fidlee]

What do you mean by "following"?


Are you sure about that? Please show us a small, complete, compilable
program that demonstrates this. On my system, the following program:

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

produces the following output:

105
105

If your system uses ASCII or an ASCII-like character set (as it almost
certainly does), the output of both printf statements should be 105.
Regardless of the character set, the output should the the same for
both statements.

sorry. my mistake.
it was actually
1)
char a='i';
printf("%d",sizeof(a));

2)
char a='i';
printf("%d",sizeof('i'));

this problem comes up in turbo C

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fidlee wrote:
[snip]

sorry. my mistake.
it was actually
1)
char a='i';

You defined [a] as a char
You initialized [a] from a character constant.
This is roughly the same as saying
char a = 43;
in that 43 is an integer, and 'i' is an integer.
But, you can still make the assignment, with a loss of precision.

printf("%d",sizeof(a));

By definition sizeof(char) is 1
So, sizeof(a) is 1

2)
char a='i';
printf("%d",sizeof('i'));

Here, you take the sizeof of a character constant.
As I said before, character constants (the things in single quotes) are
/integers/ not characters.
Apparently, on your platform, integers are 2 characters wide, so
sizeof('i')
like
sizeof(292)
will return the size of an integer constant (2).

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDrNRnagVFX4UWr64RArxwAKCUTHBJf9wM3c9Z2+S73L7s5fyd0gCgmb92
89A/GHd3MfqY1OkCzxn4hmM=
=nRIN
-----END PGP SIGNATURE-----

 

[Chuck F.]

Keith Thompson wrote:
.... snip ...
sorry. my mistake.
it was actually
1)
char a='i';
printf("%d",sizeof(a));

2)
char a='i';
printf("%d",sizeof('i'));

this problem comes up in turbo C

Congratulations on learning to quote, and to avoid silly
abbreviations. To avoid mistakes you should also always cut and
paste your code samples (from compilable source). This avoids
silly typos invalidating any conclusions.

In this newsgroup we deal only with ISO standard C. Thus the fact
that you are using Turbo C does not matter. What does matter is
that you are using only features of standard C, and no extensions
such as Turbos <conio.h> That way we are all talking about the
same language.

The differences you are seeing in your code are because 'i' is an
integer constant, and thus its size is that of an int. However it
can be stored in a char (the int is sufficiently small), and the
sizeof a char is 1 by definition.

These relative sizes, for your system, are spelled out in the
include file <limits.h> Thus your code can always adapt to the
actual situation.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

 

[fidlee]

Congratulations on learning to quote, and to avoid silly
abbreviations. To avoid mistakes you should also always cut and
paste your code samples (from compilable source). This avoids
silly typos invalidating any conclusions.

thanx a lot for the advice. I am really sorry i hadnt realised that
typing mistakes could be confusing. because I post messages from
Google Groups.

 

[Keith Thompson]

sorry. my mistake.
it was actually
1)
char a='i';
printf("%d",sizeof(a));

2)
char a='i';
printf("%d",sizeof('i'));

this problem comes up in turbo C

This demonstrates why it's important to post the actual code that you
compiled and ran. Don't try to summarize it; cut-and-paste it.
Otherwise, we can't tell which problems are in your actual code and
which were introduced when you posted it.

The "%d" format expects an int. The sizeof operator yields a value of
type size_t. It's likely to work if int and size_t happen to be the
same size, but you should make sure the types match:

printf("%d", (int)sizeof(a));
printf("%d", (int)sizeof('i'));

Finally, this isn't a problem; it's a feature. See question 8.9 in
the comp.lang.c FAQ.

 

[Emmanuel Delahaye]

fidlee a écrit :

what should be the ouptut of
printf("%d",'++');

Undefined behavour. The a character constant only have 1 character in
conforming mode.

the ascii value of + is 43... the output comes as 11051 in turboC... (i
was surprised it doesnt throw an error on compiling... ) someone
explain me as to how this output comes...

Get a better compiler, or learn how to use it properly.

Compiling: main.c
main.c:9:17: warning: multi-character character constant

In addition, you should add a '\n' to the output string to be sure it
will be displayed in time.

 

[Mark McIntyre]

fidlee a écrit :

Undefined behavour. The a character constant only have 1 character in
conforming mode.

I think you've made a mistake there. A character constant is defined
thus (6.4.4.4):

"An integer character constant is a sequence of one or more multibyte
characters enclosed in single-quotes, as in 'x'."

and further

"The value of an integer character constant containing more than one
character (e.g., 'ab'), or containing a character or escape sequence
that does not map to a single-byte execution character, is
implementation-defined."

 

[Keith Thompson]

Here, you take the sizeof of a character constant.
As I said before, character constants (the things in single quotes) are
/integers/ not characters.
Apparently, on your platform, integers are 2 characters wide, so
sizeof('i')
like
sizeof(292)
will return the size of an integer constant (2).

You missed an important distinction. A character constant isn't just
an integer; it's specifically of type int. Strictly speaking, there's
no such thing as "the size of an integer constant"; an integer
constant is a source code construct such as 42 or 0x137LL. The result
of sizeof('i') or sizeof 'i' is the same as sizeof(int).

 

[=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=]

- the width (sizeof()) of a character constant (hint: it isn't
necessarily == 1)

in fact, it is guaranteed to be at least 2.

DES

 

[Keith Thompson]

in fact, it is guaranteed to be at least 2.

No, it isn't; consider CHAR_BIT==16, sizeof(int)==1.

 

[Flash Gordon]

in fact, it is guaranteed to be at least 2.

Not it isn't. A system with CHAR_BIT==16 and sizeof(int)==1 is perfectly
valid, and I've worked on embedded systems like this.

 

[Kenny McCormack]

No, it isn't; consider CHAR_BIT==16, sizeof(int)==1.

Or how about a system on an 8 bit processor?
(I'm not sure about this - does the standard require ints to be at least 16
bits?)

 

[Richard Heathfield]

Kenny McCormack said:

(I'm not sure about this - does the standard require ints to be at least
16 bits?)

Yes.

 

[Dave Thompson]

fidlee wrote:

Yes, 'i' is a character constant in both cases, but it has type int. In
the first case you are assigning it to a type char, possibly signed
(implementation-defined), then converting the type char to int. In the
second case, you are not converting to type char. If your char type is
signed and (char)'i' is negative (depends on the character set and
number of bits in a byte), you can get different values printed.

True for characters in general, but the characters required by the
standard in the basic execution character set, including a-z A-Z 0-9,
must have positive values when stored in (plain) char, whether that
"is" signed or unsigned. (Except zero for the null character.)

In your situation, I suspect that there are other reasons that are not
visible in the snippets you posted.

That did in fact turn out to be the case elsethread.
- David.Thompson1 at worldnet.att.net