printf and cout

[pete]

santosh wrote:

The %c format expects
(and thus treats the corresponding argument as) an unsigned char.

No standard library functions are described
as taking an argument lower ranking than int.

 

[jacob navia]

No standard library functions are described
as taking an argument lower ranking than int.

Yes, but the character is promoted to int only for passing it
to printf. The expected argument is a char, not an int

 

[Richard Tobin]

Yes, but the character is promoted to int only for passing it
to printf. The expected argument is a char, not an int

It's often true that the argument is a char which gets promoted to
int, but that's not required - the standard says int, not char - and
it's often not a char. It's perfectly normal to store characters in
an int (consider the value returned by getchar() for example), and
of course character constants are ints not chars.

On the other hand, I think it's true that the only reason it's an
int is because of the deafult promotions. If it weren't for that,
it would make more sense for it to be an unsigned char.

-- Richard

 

[pete]

Yes, but the character is promoted to int only for passing it
to printf. The expected argument is a char, not an int

It's often true that the argument is a char which gets promoted to
int, but that's not required - the standard says int, not char - and
it's often not a char. It's perfectly normal to store characters in
an int (consider the value returned by getchar() for example), and
of course character constants are ints not chars.

On the other hand, I think it's true that the only reason it's an
int is because of the deafult promotions. If it weren't for that,
it would make more sense for it to be an unsigned char.[/QUOTE]

That's what I think too.

 

[Keith Thompson]

Yes, but the character is promoted to int only for passing it
to printf. The expected argument is a char, not an int

Are you saying there's something wrong, or even unexpected, with this?

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

The expected argument normally has a value that's representable as an
unsigned char, but its expected type is int.

 

[jacob navia]

Are you saying there's something wrong, or even unexpected, with this?

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

The expected argument normally has a value that's representable as an
unsigned char, but its expected type is int.

The expected argument of the printf formatting option!

That's what I am talking about. Obviously your example
will work.

printf("%c",12345678);

will not!

 

[Richard Heathfield]

jacob navia said:

The expected argument of the printf formatting option!

That's what I am talking about. Obviously your example
will work.

printf("%c",12345678);

will not!

It is certainly true that it is not guaranteed to work. It is not
guaranteed *not* to work, however. On systems with CHAR_BIT >= 24, it
/will/ work (although heaven knows what character will be printed!).

 

[Keith Thompson]

The expected argument of the printf formatting option!

That's what I am talking about.

Good, because it's also what I'm talking about.

Obviously your example
will work.

Yes, obviously it will. But if I had taken your statement above
literally:

The expected argument is a char, not an int

I'd expect it to fail.

I think I know what you *meant*, but what you actually *wrote* was
less than accurate on two counts. First, the expected argument
is an int (you clearly said it isn't). Second, the argument is
typically going to be within the range of unsigned char, not of
necessarily of plain char (though there's no prohibition on values
outside the range of unsigned char). For example, on a system with
8-bit signed plain char, there's nothing wrong or even unexpected
about ``printf("%c", 255)'' (except that I'd probably use putchar()).

printf("%c",12345678);

will not!

Actually, the behavior is well defined (if and only if 12345678
is within the range of type int). The int value is converted to
unsigned char and the resulting character is written. Assuming
UCHAR_MAX==255, the result is 78; on an ASCII-based system, this
will print 'N'. (I reached that conclusion by reading the code
and consulting the standard; a quick experiment confirmed it.)

You could say it doesn't "work" in the sense that it doesn't print
anything particularly meaningful.

Before you accuse me of playing "word games", consider that words are
the only tool we have here. You wrote that "the expected argument
is a char"; I can't think of any reasonable interpretation by which
that statement is factually correct.

 

[Kenneth Brody]

jacob navia said: [...]

That's what I am talking about. Obviously your example
will work.

printf("%c",12345678);

will not!

It is certainly true that it is not guaranteed to work. It is not
guaranteed *not* to work, however. On systems with CHAR_BIT >= 24, it
/will/ work (although heaven knows what character will be printed!).

Well, it depends on what you mean by "work". According to 7.19.6.1p8,
on the part about the "%c" format:

If no l length modifier is present, the int argument is converted
to an unsigned char, and the resulting character is written.

Is it possible to "fail" when converting an int to unsigned char? (Of
course you can lose bits, but can it "fail"?)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Ben Bacarisse]

jacob navia said:


It is certainly true that it is not guaranteed to work. It is not
guaranteed *not* to work, however. On systems with CHAR_BIT >= 24, it
/will/ work (although heaven knows what character will be
printed!).

Now I am confused! How could it "not work" on any system? The int
argument (OK so far) is converted to unsigned char (also OK on all
systems, but the result does depend on CHAR_BIT) and then the resulting
character is printed. Is it that last bit you worry about? If so
printf("%c", 32) is not "guaranteed to work" but I did not think that
was your point.

 

[jacob navia]

Good, because it's also what I'm talking about.


Yes, obviously it will. But if I had taken your statement above
literally:

The expected argument is a char, not an int

I'd expect it to fail.

I think I know what you *meant*, but what you actually *wrote* was
less than accurate on two counts. First, the expected argument
is an int (you clearly said it isn't). Second, the argument is
typically going to be within the range of unsigned char, not of
necessarily of plain char (though there's no prohibition on values
outside the range of unsigned char). For example, on a system with
8-bit signed plain char, there's nothing wrong or even unexpected
about ``printf("%c", 255)'' (except that I'd probably use putchar()).


Actually, the behavior is well defined (if and only if 12345678
is within the range of type int). The int value is converted to
unsigned char and the resulting character is written. Assuming
UCHAR_MAX==255, the result is 78; on an ASCII-based system, this
will print 'N'. (I reached that conclusion by reading the code
and consulting the standard; a quick experiment confirmed it.)

You could say it doesn't "work" in the sense that it doesn't print
anything particularly meaningful.

Before you accuse me of playing "word games", consider that words are
the only tool we have here. You wrote that "the expected argument
is a char"; I can't think of any reasonable interpretation by which
that statement is factually correct.

Well OK

"%c" format specifier expects an int.

GREAT!

I am tired of this discussion. You are right, I was wrong
and when everybody uses "%c" to put a character they are
totally wrong.

 

[Keith Thompson]

Well OK

"%c" format specifier expects an int.
Correct.

GREAT!

I am tired of this discussion.

Funny that you happen to get "tired" of it just at the moment when you
realize you made a mistake.

You are right, I was wrong

Yes, I was right. Yes, you were wrong. But it's not such a
huge deal. We all make mistakes. I make mistakes all the time,
and I'm grateful when people point them out. And I usually accept
corrections without sarcasm.

and when everybody uses "%c" to put a character they are
totally wrong.

And now you're being ridiculous. This:

char c = 'x';
printf("%c", c);

is perfectly valid, because the char value is promoted to int,
which is what printf expects for "%c". (Except in the obscure
case that plain char is unsigned and sizeof(int) == 1, but I'm
willing to ignore that (other than this brief mention for the sake
of completeness).) But of course you know that.

Pointing out an error is not a personal attack. Learn that and
you might be taken a lot more seriously around here.

 

[Richard Heathfield]

Ben Bacarisse said:

Now I am confused! How could it "not work" on any system?

if 12345678 is not representable as an int, it will fail right there. As it
turns out, though, I was being overly conservative in an attempt not to
disagree too much with Mr Navia. I was assuming (wrongly) that the int
value had to be representable as an unsigned char. It doesn't.

<snip>

 

[pete]

Funny that you happen to get "tired" of it just at the moment when you
realize you made a mistake.


Yes, I was right. Yes, you were wrong. But it's not such a
huge deal. We all make mistakes. I make mistakes all the time,
and I'm grateful when people point them out. And I usually accept
corrections without sarcasm.


And now you're being ridiculous. This:

char c = 'x';
printf("%c", c);

is perfectly valid, because the char value is promoted to int,
which is what printf expects for "%c". (Except in the obscure
case that plain char is unsigned and sizeof(int) == 1, but I'm
willing to ignore that (other than this brief mention for the sake
of completeness).) But of course you know that.

Pointing out an error is not a personal attack. Learn that and
you might be taken a lot more seriously around here.

This will output the same thing
even though the int argument is negative:

printf("%c", 'x' - 1 - (unsigned char)-1);

except in that obscure case that you mentioned.

 

[Philip Potter]

Well OK

"%c" format specifier expects an int.

GREAT!

I am tired of this discussion. You are right, I was wrong
and when everybody uses "%c" to put a character they are
totally wrong.

Jacob, Keith was perfectly civil to you. You made a mistake, and he felt
it important to point it out - not to prove you wrong, but to be
strictly correct and to ensure noone was confused by your erroneous
statement.

You are not the only one who makes mistakes and gets corrected here. For
example, Richard Heathfield makes mistakes, and his mistakes are
corrected in exactly the same manner. See
<[email protected]> from just yesterday. I don't see
why you need to take polite corrections so personally. Where others say
"oh yes, how silly of me, thank you for the correction" you complain of
personal vendettas and word games. I especially can't understand it when
the correction comes from someone as calm and civil as Keith.

As I've said before, I would much rather you were part of clc than not
part of it; you certainly have made contributions to clc and C itself.
However your passive-aggressive behaviour is a detriment to your
character, and all the noise dilutes your relevant contributions.

Philip

 

[Kenny McCormack]

....

As I've said before, I would much rather you were part of clc than not
part of it; you certainly have made contributions to clc and C itself.
However your passive-aggressive behaviour is a detriment to your
character, and all the noise dilutes your relevant contributions.

Oh. My. God.

 

[pete]

I especially can't understand it when
the correction comes from someone as calm and civil as Keith.

I can almost understand.

One of the things that I admire about Richard Heathfield
is his ability to make trolls come unglued.
Troll that are not bothered by anyone else.
Mostly I've seen this happen in comp.programming.
He does it "calm and civil"
with politeness and with with a finess
that is very difficult to describe or duplicate.

 

[Richard Heathfield]

pete said:

I can almost understand.

One of the things that I admire about Richard Heathfield
is his ability to make trolls come unglued.
Troll that are not bothered by anyone else.
Mostly I've seen this happen in comp.programming.
He does it "calm and civil"
with politeness and with with a finess
that is very difficult to describe or duplicate.

I wish I could claim that it's deliberate (because then I could simply stop
doing it) - a sort of "meta-trolling", or trolling the trolls, pushing
their buttons to make them react in their oh-so-predictable way.

But it isn't deliberate. The trigger would appear to be some facet or other
of my writing style, which many non-trolls do seem to find helpful and
clear, but which appears to drive the trolls to distraction.

When the trolls start providing useful articles about C here (i.e. when
hell freezes over, or perhaps a few months afterwards), I'll give some
thought to discovering ways in which I might change my style to avoid
"ungluing" them, as you so aptly put it. In the meantime, I'll continue
providing such help as I can to those who seek it in the way that seems
best to me, and if that means that a few bozos continue to clog up the
newsgroup with puerile nonsense, well, that's what killfiles are for,
right?

Some people don't killfile the trolls, because they find them amusing.
Obviously that's up to them. Nevertheless, I would invite such people to
consider the (fairly simple) challenge of writing a C program to mimic an
article by any of the current collection of comp.lang.c trolls. A few
stock phrases will be sufficient, I think. Slightly more challenging (but
really not *very* much more): generate random but characteristic troll
*exchanges*. You know the sort of thing:

T1: Oh. The. Irony.
T2: Yes, you're right.
T1: Too true.
T3: You're both so right.

etc.

To implement such a program in ISO C should take - oh, ten minutes, tops.

Once you've written such a program and run it a few times, you'll soon have
the shape of the solution space mapped out, after which it really ceases
to be particularly funny - at which point you may well decide to use a
killfile after all.

 

[Richard]

I can almost understand.

One of the things that I admire about Richard Heathfield
is his ability to make trolls come unglued.
Troll that are not bothered by anyone else.
Mostly I've seen this happen in comp.programming.
He does it "calm and civil"
with politeness and with with a finess
that is very difficult to describe or duplicate.

RH's skills in terms of C are without question. However he is pedantic
to the point of silliness. And that combined with his rather nasty
tendency to pick at people and wage warfare on one or two alternative,
but equally valuable, posters make him an object for ridicule rather
than admiration for most professional programmers who are used to
dealing with this type of technical ogre.

 

[pete]

RH's skills in terms of C are without question.

And on top of that,
he's one of the only seven posters to this newsgroup
who use the phrase "begging the question" correctly.