When are unnecessary casts useful?

[jacob navia]

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte. You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

I have recently added a warning to the lcc-win32 compiler system
when an assignment like this happens, to warn you about
the implicit data discarding.

To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

The cast makes your intentions clear.

The same approach exists in Microsoft compilers.

I have gotten used to do this, more or less automatically when I
cast "down", i.e. from a bigger to a smaller type.

jacob

[Richard Heathfield]

jacob navia said:

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte.

Not necessarily. On systems where char is signed and sizeof(long long) is 1,
no information will be lost. But in general, yes, that's correct.

You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

If you *are* discarding data, then you're attempting to assign to the char a
value that it cannot hold. On systems where char is unsigned by default,
that's not harmful. On systems where char is signed by default, however,
it's an overflow, and the behaviour is undefined, so the warning is a
useful one.

Whether a cast is beneficial in this situation seems to be a matter of some
dispute. Personally, I think it's unwise to use a cast to suppress a
compiler's diagnostic messages, but - without going so far as to /share/
the opposing view - I can at least see the merit therein, in cases such as
this one.

<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Jack Klein]

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia
<ja***@jacob.remcomp.frwrote in comp.lang.c:

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte. You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

I have recently added a warning to the lcc-win32 compiler system
when an assignment like this happens, to warn you about
the implicit data discarding.

To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

The cast makes your intentions clear.

The same approach exists in Microsoft compilers.

I have gotten used to do this, more or less automatically when I
cast "down", i.e. from a bigger to a smaller type.

I have absolutely no problem with this as long as there is a way to
DISABLE the warning.

There are times when there is a good reason to do non-portable things.
Most of my programming, for example, is in embedded systems with
either real time performance requirements, memory limitation issues,
or both.

A compiler could, and perhaps should, use a high warning level by
default, instead of a low warning level as most do. But there should
be a way to disable diagnostics for legal code that might have
implementation-defined or undefined behavior based on values at run
time.

This is not just a personal preference, it is about the fact that too
many spurious warnings increase the "noise level" and can cause
serious diagnostics to be overlooked.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Tue, 09 Jan 2007 13:28:31 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

jacob navia said:

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte.

Not necessarily. On systems where char is signed and sizeof(long long) is 1,
no information will be lost. But in general, yes, that's correct.

You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

If you *are* discarding data, then you're attempting to assign to the char a
value that it cannot hold. On systems where char is unsigned by default,
that's not harmful. On systems where char is signed by default, however,
it's an overflow, and the behaviour is undefined, so the warning is a
useful one.

Of course you mean, the result is implementation-defined or (on some
nonexistent platforms) an implementation-defined signal is raised.

Whether a cast is beneficial in this situation seems to be a matter of some
dispute. Personally, I think it's unwise to use a cast to suppress a
compiler's diagnostic messages, but - without going so far as to /share/
the opposing view - I can at least see the merit therein, in cases such as
this one.

<snip>

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Richard Heathfield]

Jack Klein said:

On Tue, 09 Jan 2007 13:28:31 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote in comp.lang.c:

<snip>

>If you *are* discarding data, then you're attempting to assign to the
char a value that it cannot hold. On systems where char is unsigned by
default, that's not harmful. On systems where char is signed by default,
however, it's an overflow, and the behaviour is undefined, so the warning
is a useful one.

Of course you mean, the result is implementation-defined or (on some
nonexistent platforms) an implementation-defined signal is raised.

Oops, you're right - an automatic conversion is indeed required. I take back
the overflow thing.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[David T. Ashley]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...

>
To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

The cast makes your intentions clear.

The same approach exists in Microsoft compilers.

I have gotten used to do this, more or less automatically when I
cast "down", i.e. from a bigger to a smaller type.

This comes down to one of the oldest arguments with programming, especially
with 'C'. You should look at Les Hatton's classic work, "Safer C".

Even in areas of the language that are well-defined (i.e. the compiler won't
make mistakes); statistically, humans make mistakes.

You might find in a lot of corporate coding standards the requirement that
if() conditions, be fully parenthesized, i.e.

if ((!a) || (*a 10))

An experienced programmer will argue this requirement is rubbish (i.e. any
programmer should know precedence and order of evaluation), whereas
management would argue either that (a)it is an area where people are prone
to make mistakes and/or (b)it becomes relevant when there is a team at a
mixed skill level.

This thread and all its derivatives is older than time. (Or, at least it
dates back to nearly 1972.)

[Roland Pibinger]

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:

>long long b;
char a;

....

>a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

It would make the intentions even clearer.

Best regards,
Roland Pibinger

[Richard Heathfield]

Roland Pibinger said:

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:

>>long long b;
char a;

...

>>a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

Yes, if you wrap it up in a comment or a string literal.

/* a = char(b); */ is legal, as is "a = char(b);"

It would make the intentions even clearer.

Why?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

rp*****@yahoo.com (Roland Pibinger) writes:

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:

>>long long b;
char a;

...

>>a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

No.

It would make the intentions even clearer.

How?

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

[Malcolm McLean]

"jacob navia" <ja***@jacob.remcomp.frwrote

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte. You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

OK, what does it mean to turn a long long integer into a character?
Sometimes, in really low level gubbins code, you might have to do it.
Elsewhere, it should be so rare that it deserves its own function.

Join my campaign for 64 bit ints. Then casting issues shall be magiced away.

[Ian Collins]

Malcolm McLean wrote:

"jacob navia" <ja***@jacob.remcomp.frwrote

>>In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte. You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

OK, what does it mean to turn a long long integer into a character?
Sometimes, in really low level gubbins code, you might have to do it.
Elsewhere, it should be so rare that it deserves its own function.

Or make the intent clear with something like

a = b&0xff;

Join my campaign for 64 bit ints. Then casting issues shall be magiced away.

Does that include 64 bit char?

--
Ian Collins.

[Peter Nilsson]

Richard Heathfield wrote:

jacob navia said:

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte.

Not necessarily. On systems where char is signed and sizeof(long long) is 1,
no information will be lost.

It can still be lost if [S]CHAR_MAX < LLONG_MAX on said implementation.
Though it would be a particularly evil implementation.

But in general, yes, that's correct.

--
Peter

[Peter Nilsson]

Your subject is generic, but your post is quite particular.

jacob navia wrote:

In one of the previous discussions I received a note from
C.B. Falconer indicating me that a cast from long long
to int was unnecessary since the compiler will do that
without the cast automatically.

This is true, but:

Suppose

long long b;
char a;

a = b;

In this assignment, the long long is truncated to a byte. You do
not need a cast in principle to do this, but you are discarding
data when you do this assignment.

Depends what was in b to begin with.

I have recently added a warning to the lcc-win32 compiler system
when an assignment like this happens, to warn you about
the implicit data discarding.

Does lcc-win32 warn you when the pizza's getting cold? That one might
actually be useful. ;-)

To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

MUCH better would be if the warning can be disabled from a compiler
option. Your thinking all but forces impressionable newbies to change
their programming style (probably for the worse), and experienced hands
to get cheesed off at unnecessary warnings.

The cast makes your intentions clear.

And what if the type of b changes to a wider type? Whoever maintains
the
code will have to sift through the source looking for spurious casts.

The same approach exists in Microsoft compilers.

Figures.

<snip>

--
Peter

[Yevgen Muntyan]

Peter Nilsson wrote:

Your subject is generic, but your post is quite particular.

jacob navia wrote:

[snip]

>>I have recently added a warning to the lcc-win32 compiler system
when an assignment like this happens, to warn you about
the implicit data discarding.

Does lcc-win32 warn you when the pizza's getting cold? That one might
actually be useful. ;-)

>>To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

MUCH better would be if the warning can be disabled from a compiler
option. Your thinking all but forces impressionable newbies to change
their programming style (probably for the worse), and experienced hands
to get cheesed off at unnecessary warnings.

>>The cast makes your intentions clear.

And what if the type of b changes to a wider type? Whoever maintains
the
code will have to sift through the source looking for spurious casts.

>>The same approach exists in Microsoft compilers.

Figures.

GCC and Intel compiler have this thing too, it's not like some
evil microsoft invention picked up by Jacob Navia. You don't want
it you don't use it.

Regards,
Yevgen

[CBFalconer]

Peter Nilsson wrote:

jacob navia wrote:

.... snip ...

>

>To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

MUCH better would be if the warning can be disabled from a compiler
option. Your thinking all but forces impressionable newbies to change
their programming style (probably for the worse), and experienced
hands to get cheesed off at unnecessary warnings.

Better, from the point of view of training newbies, and from the
point of view of simplicity, is to trigger a warning for ANY cast:

"Warning - possibly erroneous cast encountered".

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[ais523]

David T. Ashley wrote:

You might find in a lot of corporate coding standards the requirement that
if() conditions, be fully parenthesized, i.e.

if ((!a) || (*a 10))

You might find that the extra parentheses have an effect on some
compilers. For instance, if there's an assignment used as the if
condition:

%cat -n test.c
1 int main(void)
2 {
3 char c='c';
4 char* a;
5 a=&c;
6 if(!a || *a 10) c++;
7 if((!a) || (*a 10)) c++;
8 if(*a = 10) c++;
9 if((*a = 10)) c++;
10 return 0;
11 }
%gcc -W -Wall test.c
test.c: In function `main':
test.c:8: warning: suggest parentheses around assignment used as truth
value

Note that my version of gcc hasn't warned on line 9; it takes the extra
parentheses as an instruction to suppress the warning. So excess
parenthesisation of this sort can have an effect on compiler
diagnostics, even if it doesn't affect the behaviour of the code.
--
ais523

[Roland Pibinger]

On Tue, 09 Jan 2007 18:22:32 +0000, Richard Heathfield wrote:

>Roland Pibinger said:

>BTW, is it legal in C to write:
a = char(b);

Yes, if you wrap it up in a comment or a string literal.

/* a = char(b); */ is legal, as is "a = char(b);"

>It would make the intentions even clearer.

Why?

Well, I guess I'm too much influenced by C++ in that case.

[Richard Bos]

rp*****@yahoo.com (Roland Pibinger) wrote:

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:

long long b;
char a;

...

a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

It would make the intentions even clearer.

You mean you find calling the char function with an argument of b a
clearer way of expressing "cast the value of b to char" than using a
char-typed cast operator on b? Interesting...

Richard

[Steffen Buehler]

Richard Bos wrote:

rp*****@yahoo.com (Roland Pibinger) wrote:

>On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:

>long long b;
char a;

...

>a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

It would make the intentions even clearer.

You mean you find calling the char function with an argument of b a
clearer way of expressing "cast the value of b to char" than using a
char-typed cast operator on b? Interesting...

Interesting or not, I prefer the latter expression, too. Functions look
more elegant to me than ugly cast operators. What's more,

a = char(b+c*c-d);

saves some keystrokes compared to

a = (char)(b+c*c-d);

Regards
Steffen

[matevzb]

On Jan 10, 1:13 pm, Steffen Buehler <[e-mail]>
wrote:

Richard Bos wrote:

[e-mail] (Roland Pibinger) wrote:

On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:
long long b;
char a;
...
a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

It would make the intentions even clearer.

You mean you find calling the char function with an argument of b a
clearer way of expressing "cast the value of b to char" than using a
char-typed cast operator on b? Interesting...Interesting or not, I prefer the latter expression, too. Functions look

more elegant to me than ugly cast operators. What's more,

a = char(b+c*c-d);

This isn't C, it's a C++ constructor if I'm not mistaken. It has a
different meaning than a cast, it is however nevertheless ugly. Almost
as ugly as the abuse ("overloading") of the shift operator.

saves some keystrokes compared to

a = (char)(b+c*c-d);

If I had a penny for each bug I found due to someone "saving some
keystrokes"...
--
WYCIWYG - what you C is what you get

[Clark S. Cox III]

matevzb wrote:

On Jan 10, 1:13 pm, Steffen Buehler <[e-mail]>
wrote:

>Richard Bos wrote:

>>[e-mail] (Roland Pibinger) wrote:
On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:
long long b;
char a;
...
a = (char)b;
The cast makes your intentions clear.
BTW, is it legal in C to write:
a = char(b);
It would make the intentions even clearer.
You mean you find calling the char function with an argument of b a
clearer way of expressing "cast the value of b to char" than using a
char-typed cast operator on b? Interesting...Interesting or not, I prefer the latter expression, too. Functions look

more elegant to me than ugly cast operators. What's more,

a = char(b+c*c-d);

This isn't C, it's a C++ constructor if I'm not mistaken. It has a
different meaning than a cast, it is however nevertheless ugly.

<OT>
No, it is a cast, albeit with a different syntax. In C++, the following
are semantically identical:

char(b+c*c-d)
(char)(b+c*c-d)
</OT>

Almost as ugly as the abuse ("overloading") of the shift operator.

>saves some keystrokes compared to

a = (char)(b+c*c-d);

If I had a penny for each bug I found due to someone "saving some
keystrokes"...

<OT>
Though it does "save some keystrokes" (which, I agree is a horrible
justification for allowing something), that is not the reason for
allowing that syntax.
</OT>
--
Clark S. Cox III
cl*******@gmail.com

[David T. Ashley]

"ais523" <ai****@bham.ac.ukwrote in message
news:11**********************@p59g2000hsd.googlegr oups.com...

%cat -n test.c
1 int main(void)
2 {
3 char c='c';
4 char* a;
5 a=&c;
6 if(!a || *a 10) c++;
7 if((!a) || (*a 10)) c++;
8 if(*a = 10) c++;
9 if((*a = 10)) c++;
10 return 0;
11 }
%gcc -W -Wall test.c
test.c: In function `main':
test.c:8: warning: suggest parentheses around assignment used as truth
value

Note that my version of gcc hasn't warned on line 9; it takes the extra
parentheses as an instruction to suppress the warning. So excess
parenthesisation of this sort can have an effect on compiler
diagnostics, even if it doesn't affect the behaviour of the code.

The behavior you illustrated is unexpected. What a surprise!

We all know that one of the most frequent human errors (at least, until
you've used 'C' for a long time) is to write something like:

if (x=0)

when you really mean

if (x==0)

so I'm not surprised that the compiler will flag that.

But that the extra parens suppress it really surprises me.

Maybe the rationale was if you parenthesize it you are saying "Yo, compiler,
I do understand that this assignment has a value, and I want the value of
it".

Or (although I doubt it), it could be bug in the compiler.

I've never seen this. Thanks.

[Peter Nilsson]

Yevgen Muntyan wrote:

Peter Nilsson wrote:

jacob navia wrote:

...
To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:
>
a = (char)b;

MUCH better would be if the warning can be disabled from a compiler
option....

The cast makes your intentions clear.
...
The same approach exists in Microsoft compilers.

Figures.

GCC and Intel compiler have this thing too, it's not like some
evil microsoft invention picked up by Jacob Navia. You don't want
it you don't use it.

But unlike gcc, from what Jacob has said, he isn't giving me the option
of disabling the warning.

I don't mind warnings. What I mind is compiler writers telling me and
other programers, via pester power, what is and what isn't good
practice.
Down conversions are useful and not at all uncommon in C, viz...

char *s = buffer;
int ch = getchar();
*s++ = ch;

If lcc-win32 gives a warning everytime for such code, whether I want it
too or not, chances are I would stop using lcc-win32 quite quickly.

--
Peter

[jacob navia]

Peter Nilsson a écrit :

Yevgen Muntyan wrote:

>>Peter Nilsson wrote:

>>>jacob navia wrote:

...
To avoid the warning you have to explicitely cast the LHS to meet
the RHS, like this:

a = (char)b;

MUCH better would be if the warning can be disabled from a compiler
option....
The cast makes your intentions clear.
...
The same approach exists in Microsoft compilers.

Figures.

GCC and Intel compiler have this thing too, it's not like some
evil microsoft invention picked up by Jacob Navia. You don't want
it you don't use it.

But unlike gcc, from what Jacob has said, he isn't giving me the option
of disabling the warning.

I don't mind warnings. What I mind is compiler writers telling me and
other programers, via pester power, what is and what isn't good
practice.
Down conversions are useful and not at all uncommon in C, viz...

char *s = buffer;
int ch = getchar();
*s++ = ch;

If lcc-win32 gives a warning everytime for such code, whether I want it
too or not, chances are I would stop using lcc-win32 quite quickly.

This warning is enabled when you increase the warning level from the
default one, or when you invoke the compiler in "check" mode.

[Keith Thompson]

Steffen Buehler <st*************@mailinator.comwrites:

Richard Bos wrote:

>rp*****@yahoo.com (Roland Pibinger) wrote:

>>On Tue, 09 Jan 2007 14:16:29 +0100, jacob navia wrote:
long long b;
char a;
...
a = (char)b;

The cast makes your intentions clear.

BTW, is it legal in C to write:

a = char(b);

It would make the intentions even clearer.

You mean you find calling the char function with an argument of b a
clearer way of expressing "cast the value of b to char" than using a
char-typed cast operator on b? Interesting...

Interesting or not, I prefer the latter expression, too. Functions look
more elegant to me than ugly cast operators.

[...]

If cast operators are ugly, that's a feature, not a bug. Discouraging
the use of unnecessary casts (as most of them are) is a good thing.
(I don't find the syntax ugly, but YMMV.)

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

[Simon Biber]

David T. Ashley wrote:

"ais523" <ai****@bham.ac.ukwrote in message
news:11**********************@p59g2000hsd.googlegr oups.com...

>%cat -n test.c
1 int main(void)
2 {
3 char c='c';
4 char* a;
5 a=&c;
6 if(!a || *a 10) c++;
7 if((!a) || (*a 10)) c++;
8 if(*a = 10) c++;
9 if((*a = 10)) c++;
10 return 0;
11 }
%gcc -W -Wall test.c
test.c: In function `main':
test.c:8: warning: suggest parentheses around assignment used as truth
value

Note that my version of gcc hasn't warned on line 9; it takes the extra
parentheses as an instruction to suppress the warning. So excess
parenthesisation of this sort can have an effect on compiler
diagnostics, even if it doesn't affect the behaviour of the code.

[..]

But that the extra parens suppress it really surprises me.

The text of the diagnostic message clearly suggests adding brackets to
assignments used as truth values. There must be a reason for doing so --
perhaps as mundane as simply to suppress the warning.

Maybe the rationale was if you parenthesize it you are saying "Yo, compiler,
I do understand that this assignment has a value, and I want the value of
it".

Yes, exactly.

Or (although I doubt it), it could be bug in the compiler.

No. It's by design.

Unfortunately not all compilers take the hint when you just add brackets
-- some will continue to warn you. So I've taken to adding both brackets
and != 0 to the end:

if((x = y) != 0)

This is pretty warning-proof.

--
Simon.

[CBFalconer]

"David T. Ashley" wrote:

"ais523" <ai****@bham.ac.ukwrote in message

>%cat -n test.c
1 int main(void)
2 {
3 char c='c';
4 char* a;
5 a=&c;
6 if(!a || *a 10) c++;
7 if((!a) || (*a 10)) c++;
8 if(*a = 10) c++;
9 if((*a = 10)) c++;
10 return 0;
11 }
%gcc -W -Wall test.c
test.c: In function `main':
test.c:8: warning: suggest parentheses around assignment used as
truth value

Note that my version of gcc hasn't warned on line 9; it takes the
extra parentheses as an instruction to suppress the warning. So
excess parenthesisation of this sort can have an effect on compiler
diagnostics, even if it doesn't affect the behaviour of the code.

The behavior you illustrated is unexpected. What a surprise!

We all know that one of the most frequent human errors (at least,
until you've used 'C' for a long time) is to write something like:

if (x=0)

when you really mean

if (x==0)

so I'm not surprised that the compiler will flag that.

But that the extra parens suppress it really surprises me.

Maybe the rationale was if you parenthesize it you are saying "Yo,
compiler, I do understand that this assignment has a value, and I
want the value of it".

Or (although I doubt it), it could be bug in the compiler.

No bug. in "if (x = 0) {" the tested item is an assignment
statement, which incidentally also yields a value. In "if ((x =
0)) {" the tested statement is a parenthized expression, which
intrincically has a value, and the compiler can tell what is going
on. Of course the sane thing to do is to write those as "if (0 =
x)", assuming you want to test against 0 and avoid failing to flag
the erroneous assignment statement.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:
[...]

No bug. in "if (x = 0) {" the tested item is an assignment
statement, which incidentally also yields a value. In "if ((x =
0)) {" the tested statement is a parenthized expression, which
intrincically has a value, and the compiler can tell what is going
on.

The expression is effectively identical with or without the
parentheses. Strictly speaking, the form without the parentheses is
not an "assignment statement"; it's not a statement at all, and an
assignment is an expression, not a statement. (Like any expression,
you can make it an expression by adding a semicolon.) Both forms have
exactly the same result, side effects, and any other semantics you can
think of.

The compiler's decision to issue a warning only for the
unparenthesized form is reasonable, since that form is far more likely
to be the result of mistyping "==" as "=", but as far as the language
is concerned it's essentially arbitrary.

Of course the sane thing to do is to write those as "if (0 =
x)", assuming you want to test against 0 and avoid failing to flag
the erroneous assignment statement.

(I've expressed my opinion on this kind of thing before; I won't bore
everyone by doing so again here.)

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

[David T. Ashley]

"Simon Biber" <ne**@ralmin.ccwrote in message
news:45**********@news.peopletelecom.com.au...

This is pretty warning-proof.

This is my first time seeing the term "warning-proof". It suggests a
programmer who has been harrassed by compilers throughout a long career. It
has the flavor of a woman saying "stalker-proof".

[Malcolm McLean]

"Ian Collins" <ia******@hotmail.comwrote in message

>

>Join my campaign for 64 bit ints. Then casting issues shall be magiced
away.

Does that include 64 bit char?

Ideally the char / byte link would be broken, and a byte would become an
octet, with compiler gyrations for the few platforms where that is a
problem. chars would then be characters, and integer operations on them
could be deprecated and later disallowed.

However it is unlikely to happen. 64 bit ints are achieveable without
changing the standard.

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

[Chris Dollin]

Malcolm McLean wrote:

"Ian Collins" <ia******@hotmail.comwrote in message

>>

>>Join my campaign for 64 bit ints. Then casting issues shall be magiced
away.

Does that include 64 bit char?

Ideally the char / byte link would be broken, and a byte would become an
octet, with compiler gyrations for the few platforms where that is a
problem. chars would then be characters, and integer operations on them
could be deprecated and later disallowed.

However it is unlikely to happen. 64 bit ints are achieveable without
changing the standard.

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

Well, (a) we are no longer in the glory days of the BBC Model B, where
an 8x8 programable character definition was really rather whizzy, and
(b) some moderately well-known character sets wouldn't fit that
definition and (c) it confuses the character with a particular
bitmapped presentation.

--
Chris "first on the Underground!" Dollin
"Who do you serve, and who do you trust?" /Crusade/

[Simon Biber]

David T. Ashley wrote:

"Simon Biber" <ne**@ralmin.ccwrote in message
news:45**********@news.peopletelecom.com.au...

>This is pretty warning-proof.

This is my first time seeing the term "warning-proof". It suggests a
programmer who has been harrassed by compilers throughout a long career. It
has the flavor of a woman saying "stalker-proof".

Not a terribly long career in C. I have been programming for 19 years
but only 6 years in C. I like all my code to compile cleanly, and that
means with no warnings. Preferably on the highest sane [1] warning level.

[1] I reserve the right to define 'sane' however I like. For example,
currently it's simply -Wall -W -O2 on gcc.

--
Simon.

[Mark McIntyre]

On Sun, 14 Jan 2007 07:17:52 +1100, in comp.lang.c , Simon Biber
<ne**@ralmin.ccwrote:

>Not a terribly long career in C. I have been programming for 19 years
but only 6 years in C. I like all my code to compile cleanly, and that
means with no warnings.

I sympathise with this. Its frequently extremely difficult if you use
and of the MS compiler headers mind you...
--
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 Heathfield]

Mark McIntyre said:

On Sun, 14 Jan 2007 07:17:52 +1100, in comp.lang.c , Simon Biber
<ne**@ralmin.ccwrote:

>>Not a terribly long career in C. I have been programming for 19 years
but only 6 years in C. I like all my code to compile cleanly, and that
means with no warnings.

I sympathise with this. Its frequently extremely difficult if you use
and of the MS compiler headers mind you...

In VS6, the only standard header I know of that provokes a diagnostic
message, even at the highest level, is math.h (because it contains a BCPL
comment). Are you saying VS has got worse since then?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[matevzb]

On Jan 14, 5:45 pm, Richard Heathfield <[e-mail]:

Mark McIntyre said:

On Sun, 14 Jan 2007 07:17:52 +1100, in comp.lang.c , Simon Biber
<[e-mail]:

>Not a terribly long career in C. I have been programming for 19 years
but only 6 years in C. I like all my code to compile cleanly, and that
means with no warnings.

I sympathise with this. Its frequently extremely difficult if you use
and of the MS compiler headers mind you...

In VS6, the only standard header I know of that provokes a diagnostic
message, even at the highest level, is math.h (because it contains a BCPL
comment). Are you saying VS has got worse since then?

Yes, very much so. The following code
#include <stdio.h>

int
main (void)
{
int i = 10;
char str[256];

sprintf (str, "%d", i);
return 0;
}
produces a warning in VC 2005 (express).
c:\tmp\a.c(8) : warning C4996: 'sprintf' was declared deprecated
c:\program files\microsoft visual studio
8\vc\include\stdio.h(345) : see declaration of 'sprintf'
Message: 'This function or variable may be unsafe. Consider using
sprintf_s instead. To disable deprecation, use
_CRT_SECURE_NO_DEPRECATE. See online help for details.'
In my experience VC got quite worse in other areas as well.
--
WYCIWYG

[Richard Heathfield]

matevzb said:

On Jan 14, 5:45 pm, Richard Heathfield wrote:

>Are you saying VS has got worse since then?

Yes, very much so. The following code
#include <stdio.h>

int
main (void)
{
int i = 10;
char str[256];

sprintf (str, "%d", i);
return 0;
}
produces a warning in VC 2005 (express).
c:\tmp\a.c(8) : warning C4996: 'sprintf' was declared deprecated

Oh dear.

Well, it's legal. They can say "warning: send Bill more money" if they like,
and it would still be conforming. But a plethora of spurious warnings is
not going to win Visual Studio any customers, and may well be sufficient to
drive old customers into the arms of other suppliers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Randy Howard]

On Sun, 14 Jan 2007 11:35:43 -0600, Richard Heathfield wrote
(in article <G7*********************@bt.com>):

matevzb said:

>On Jan 14, 5:45 pm, Richard Heathfield wrote:

>>Are you saying VS has got worse since then?

Yes, very much so. The following code
#include <stdio.h>

int
main (void)
{
int i = 10;
char str[256];

sprintf (str, "%d", i);
return 0;
}
produces a warning in VC 2005 (express).
c:\tmp\a.c(8) : warning C4996: 'sprintf' was declared deprecated

Oh dear.

Well, it's legal. They can say "warning: send Bill more money" if they like,
and it would still be conforming. But a plethora of spurious warnings is
not going to win Visual Studio any customers, and may well be sufficient to
drive old customers into the arms of other suppliers.

That's what happened here. Good riddance to bad rubbish.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Mark McIntyre]

On Sun, 14 Jan 2007 16:45:33 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:

>Mark McIntyre said:

>On Sun, 14 Jan 2007 07:17:52 +1100, in comp.lang.c , Simon Biber
<ne**@ralmin.ccwrote:

>>>Not a terribly long career in C. I have been programming for 19 years
but only 6 years in C. I like all my code to compile cleanly, and that
means with no warnings.

I sympathise with this. Its frequently extremely difficult if you use
and of the MS compiler headers mind you...

In VS6, the only standard header I know of that provokes a diagnostic
message, even at the highest level, is math.h (because it contains a BCPL
comment). Are you saying VS has got worse since then?

I'm not actually sure its *possible* for some compilers to get /worse/
at producing annoying messages when on sensible warninglevels...

(FWIW its massively worse when you're using any of the Win32 headers,
these are packed with L3 and L4 warnings)

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

[CBFalconer]

Mark McIntyre wrote:

Richard Heathfield <rj*@see.sig.invalidwrote:

.... snip ...

>

>In VS6, the only standard header I know of that provokes a diagnostic
message, even at the highest level, is math.h (because it contains a
BCPL comment). Are you saying VS has got worse since then?

I'm not actually sure its *possible* for some compilers to get /worse/
at producing annoying messages when on sensible warninglevels...

(FWIW its massively worse when you're using any of the Win32 headers,
these are packed with L3 and L4 warnings)

A vendor doesn't have to make his headers pass the warning levels,
because they are specific to the implementation. However he should
have the intelligence to suppress warnings from those constructs in
those headers. MS doesn't.

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

[Giorgos Keramidas]

On Thu, 11 Jan 2007 07:43:21 -0000,
"Malcolm McLean" <re*******@btinternet.comwrote:

>"Ian Collins" <ia******@hotmail.comwrote in message

>>Join my campaign for 64 bit ints. Then casting issues shall be magiced
away.

Does that include 64 bit char?

[...]
How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

<OT>
Or a utf-16 glyph index *and* lots of space for metadata, which smart
editors would use to keep other sorts of information.
</OT>

But this is quickly getting way off-topic :)

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks (and 8x8 bits would be inadequate for that anyway).

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

[Keith Thompson]

"Harald van Dþÿ
3k" <tr*****@gmail.comwrites:

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And the values of the characters '0' through '9' would no longer be
contiguous.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

I see no point in tying the type char to any particular font (assuming
that's what Malcolm has in mind).

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

[Keith Thompson]

"Harald van D_k" <tr*****@gmail.comwrites:

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And the values of the characters '0' through '9' would no longer be
contiguous.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

I see no point in tying the type char to any particular font (assuming
that's what Malcolm has in mind).

[My first reply was incorrect tagged "charset=utf-16be", so I'm
re-posting. I'll try to fix whatever's causing that.]

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Keith Thompson wrote:

"Harald van D_k" <tr*****@gmail.comwrites:

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.
>
How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And the values of the characters '0' through '9' would no longer be
contiguous.

Good point. You'd need a special exception in that system, swapping
the character containing the representation of '0' with an otherwise
unused representation, and similarly for the other digits.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

I see no point in tying the type char to any particular font (assuming
that's what Malcolm has in mind).

If I ignore your previous paragraph here, there could be a rare
exception: a system that already uses 64-bit chars anyway, and where
the font cannot be changed, and where even in text mode any
combination of pixels can be printed in a character block. Generally
speaking though, neither do I, and even that system should probably be
redesigned to allow the font to be changed, since the hardware is
clearly capable of it.

[My first reply was incorrect tagged "charset=utf-16be", so I'm
re-posting. I'll try to fix whatever's causing that.]

You've said it's caused by my name, but you're the first I've seen
have this particular problem with it, so no idea here, sorry.

[Nelu]

Keith Thompson <ks***@mib.orgwrote:

"Harald van D??
3k" <tr*****@gmail.comwrites:

>Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And the values of the characters '0' through '9' would no longer be
contiguous.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

I see no point in tying the type char to any particular font (assuming
that's what Malcolm has in mind).

Is the utf16-be you're using, again, related to the discussion? :-)).
Or is it just my reader?...

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

[Walter Roberson]

In article <11**********************@v45g2000cwv.googlegroups .com>,
=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= <tr*****@gmail.comwrote:

>Keith Thompson wrote:

>"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

>How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

>They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

You'd have fun writing a time-and-space efficient toupper()
and so on.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[CBFalconer]

Walter Roberson wrote:

<tr*****@gmail.comwrote:

>Keith Thompson wrote:

>>"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
How many bits you need for a char depends on your language. 64 is
a good choice, however, because then the bits can be a 8x8 raster.

>>How is an 8x8 raster useful? We're talking about a representation
of a character code, not a graphical representation of what the
character looks

>They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc.
(My apologies if I got the number wrong.)

You'd have fun writing a time-and-space efficient toupper()
and so on.

You make the matrix hold a 6 wide by 8 high bit map, leaving two 8
bit areas free, to hold the equivalent ascii char and an 8 bit
attribute set. An attribute bit can shift thing down 2 bits,
allowing for descenders. The result is displayed in a 6 by 10
field, nicely compatible with most scans.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Richard Bos]

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]

How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.

How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And what about if you wanted both an all-white _and_ an all-black square
in your charset? You wouldn't be able to have a null character, then.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

An 8x8 font is itself clearly not enough. It was good enough for 1980's
English-only home computers; it's not enough for anything serious today.

Richard

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Bos wrote:

"=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=" <tr*****@gmail.comwrote:

Keith Thompson wrote:

"Malcolm McLean" <re*******@btinternet.comwrites:
[...]
How many bits you need for a char depends on your language. 64 is a good
choice, however, because then the bits can be a 8x8 raster.
>
How is an 8x8 raster useful? We're talking about a representation of
a character code, not a graphical representation of what the character
looks

They could be equal. With 64-bit chars, ' ' could be equal to
0xFFFFFFFFFFFFFFFF, 'A' could be equal to 0xFFE7DBDBC3DBDBFF, etc. (My
apologies if I got the number wrong.)

And what about if you wanted both an all-white _and_ an all-black square
in your charset? You wouldn't be able to have a null character, then.

Sure you would. The all-black square would be the null character. You
wouldn't be able to store it in C strings, but you would be able to
read and write it using the standard C character-based I/O functions.

(and 8x8 bits would be inadequate for that anyway).

It's enough if you use an 8x8 font.

An 8x8 font is itself clearly not enough. It was good enough for 1980's
English-only home computers; it's not enough for anything serious today.

I hope you mean it's not enough for everything serious today.