Strange - a simple assignment statement shows error in VC++ but worksin gcc !

[peter koch]

Hmm.  My remarks were addressed to peter koch, who wrote:
| But I also have a very strong dislike for conversions, and one of the
| rules - at least in C - should be that you do not have any conversion
| that is not accompagnied by a comment. If this simple and good rule is
| adhered to, none of the problems mentioned in this discussion would
| surface.

This is of course a public forum, and you're free to respond, but you
give the impression that you're speaking on his behalf.  I don't see
how you can be sure of what he meant.

The idea that all casts should be accompanied by comments is an
interesting one (to me, at least).

This was what I tried to convey - unfortunately using the wrong
wording (conversion instead of cast).
And again: the other alternative would be to silence the warnings
according to your policy. I believe that the warnings are appropriate
and should be silenced with a cast (and a comment) unless they are of
the ludicrous type David Schwartz showed us earlier.

/Peter

 

[Keith Thompson]

[...]> But I also have a very strong dislike for conversions, and one of the

rules - at least in C - should be that you do not have any conversion
that is not accompagnied by a comment. If this simple and good rule is
adhered to, none of the problems mentioned in this discussion would
surface.

[snip]
C is so full of implicit conversions that trying to comment all of
them is likely to result in more comments than code.  On the other
hand, if you want to require comments for some subset of conversions,
that might be reasonable -- assuming you can define the subset clearly
enough.

(I'm assuming you really meant "conversions", not "casts".)

Very nice one, but I kind of doubt that last statement. I naturally
meant explicit conversion, in C: cast.

Ok, then most of what I wrote (and snipped in this followup) is
irrelevant -- and David Schwartz failed in his attempt to read your
mind }.

Please note that this thread is cross-posted to comp.lang.c, which
is where I'm reading it. We try to distinguish very clearly between
casts (i.e., uses of the cast operator, a parenthesized type name
which precedes an expression) and conversions (which may be either
explicit, via a cast operator, or implicit). (Note that "explicit
cast" is redundant, and "implicit cast" is a contradiction -- not
that you used either phrase.) So when you said that all conversions
should be accompanied by a comment, I naturally assumed you meant
*all* conversions, including implicit ones.

Yes, a coding standard that requires a comment (presumably a
non-trivial one) for each cast is an interesting idea. Casts should,
IMHO, be rare enough that this isn't a burden.

 

[peter koch]

Ok, then most of what I wrote (and snipped in this followup) is
irrelevant -- and David Schwartz failed in his attempt to read your
mind }.

Okay, I believed your entire post to be an attempted joke ;-)

Please note that this thread is cross-posted to comp.lang.c, which
is where I'm reading it.  We try to distinguish very clearly between
casts (i.e., uses of the cast operator, a parenthesized type name
which precedes an expression) and conversions (which may be either
explicit, via a cast operator, or implicit).  

I did notice the crosspost and as already explained, my intention was
to use the word "cast". A non-freudian slip, most likely.

(Note that "explicit
cast" is redundant, and "implicit cast" is a contradiction -- not
that you used either phrase.)  So when you said that all conversions
should be accompanied by a comment, I naturally assumed you meant
*all* conversions, including implicit ones.

Yes, a coding standard that requires a comment (presumably a
non-trivial one) for each cast is an interesting idea.  Casts should,
IMHO, be rare enough that this isn't a burden.

Exactly. I heard about 1500 casts in a 450000 line program and the
ratio struck me as rather high. But since I changed from C to C++
around 1996 and as I remember writing far more casts as a C-programmer
than as a C++ programmer, I decided not to comment those statistics.
Even then, this amount of comments should not be to big a burden.

/Peter

 

[Keith Thompson]

Okay, I believed your entire post to be an attempted joke ;-)

That's ok; I've been accused of far worse. }

[...]

 

[Rainer Weikusat]

[...]

Yes, a coding standard that requires a comment (presumably a
non-trivial one) for each cast is an interesting idea.  Casts should,
IMHO, be rare enough that this isn't a burden.

Exactly. I heard about 1500 casts in a 450000 line program and the
ratio struck me as rather high. But since I changed from C to C++
around 1996 and as I remember writing far more casts as a C-programmer
than as a C++ programmer, I decided not to comment those statistics.
Even then, this amount of comments should not be to big a burden.

The implicit assumption here is that 'cast' means there is actually
something worthy to comment on. Two examples where this is at least
questionable would be

rc = bind(fd, (struct sockaddr *)&sin, sizeof(sin))[*]

and casting a pointer to an uintptr_t in order to perform mathematical
operations on the value, like ensuring a particular alignment.

[*] The people who designed 'BSD sockets' used 'struct sockaddr'
as a way to pass addresses of different types ('address families')
to and from 'the networking stack' using a uniform set of multiplexer
calls (bind/ connect/ getpeername/ getsockname etc).

 

[David Schwartz]

This was what I tried to convey - unfortunately using the wrong
wording (conversion instead of cast).
And again: the other alternative would be to silence the warnings
according to your policy. I believe that the warnings are appropriate
and should be silenced with a cast (and a comment) unless they are of
the ludicrous type David Schwartz showed us earlier.

Okay, I thought I knew what you were saying and now I'm not sure I do.

Correct me if I'm wrong: You are saying that conversions that are
potentially unsafe (by some reasonable standard) should be accompanied
by both a cast and a comment saying that the conversion is known safe?

I suppose I could think of some coding environments where that might
be appropriate, but not in any professional one. If a programmer
explicitly and clearly tells the compiler to do something, then he
must already think that that's safe. So it's completely redundant.

The only scenario it prevents (a programmer deliberately adds a cast
he does not vouch for the safety of) is better solved simply by
prohibiting it. A rule like "A programmer may not add a cast unless he
has made sure that cast is safe. Requesting a conversion explicitly is
vouching for its safety" not only makes eminent sense but avoids
completely redundancy.

I mean, why not requires "i++;" to have a comment "I have made sure it
is safe to add one to 'i' here"? The reason is obvious -- the
programmer clearly intended to add one to 'i', so he must have thought
it was safe.

There is only an issue when the consequences of code are not
completely obvious.

DS

 

[David Schwartz]

for me in every case, above is always wrong

So what would you recommend when the function to get the size of a
stored object returns a int64_t and the function to process a
configuration object with a max size of 8Kb takes an unsigned?

unsigned GetConfigurationObjectSize(void)
{
unsigned ret;
int64_t s=GetObjectSize(ConfigurationObject);
if( (s<=0) || (s>MAX_CONFIG_OBJECT_SIZE) ) return 0;
/* something goes here */
return ret;
}

DS

 

[Mark Wooding]

So what would you recommend when the function to get the size of a
stored object returns a int64_t and the function to process a
configuration object with a max size of 8Kb takes an unsigned?

assert.

-- [mdw]

 

[peter koch]

Okay, I thought I knew what you were saying and now I'm not sure I do.

Ouch - I'm sorry about the fuss.

Correct me if I'm wrong: You are saying that conversions that are
potentially unsafe (by some reasonable standard) should be accompanied
by both a cast and a comment saying that the conversion is known safe?

Nope. What I meant to say was that any explicit cast (in C) should be
accompagnied by a comment. After that rule is it up to yourself to
decide when a cast is needed: if you decide to compile with warnings
for lossy conversions, you need to cast - and in that case also to
comment - this is assuming that you sensible require clean compiles.

I myself like those warnings, but somehow gcc seems to be stricter
than MSVC, and for the example you gave, the warning was simply silly.

I suppose I could think of some coding environments where that might
be appropriate, but not in any professional one. If a programmer
explicitly and clearly tells the compiler to do something, then he
must already think that that's safe. So it's completely redundant.

I don't really know. You assume of course that the programmer knows
what he's doing, but for those who ned to read the code later the
comment would not be wasted.

The only scenario it prevents (a programmer deliberately adds a cast
he does not vouch for the safety of) is better solved simply by
prohibiting it. A rule like "A programmer may not add a cast unless he
has made sure that cast is safe. Requesting a conversion explicitly is
vouching for its safety" not only makes eminent sense but avoids
completely redundancy.

I mean, why not requires "i++;" to have a comment "I have made sure it
is safe to add one to 'i' here"? The reason is obvious -- the
programmer clearly intended to add one to 'i', so he must have thought
it was safe.

But i++ is inherently safe - at least on most common archtectures. And
certainly there's nothing complicated going on, it is obvious what
happens.
If you take a statement such as y = (T)x; everything gets much more
complicated, and it is not so obvious anymore, at least to me ;-). The
purpose could be to cast away const, it could be to look at a pointer
as an integer value (e.g. for hashing), and it could be to inspect a
structure as raw bytes. It could also be to do stuff, you should not
mention out loud if there's children present,so ill stop right now.
But: lots of options are possible, and the comment would often be
useful.

/Peter

 

[Keith Thompson]

Correct me if I'm wrong: You are saying that conversions that are
potentially unsafe (by some reasonable standard) should be accompanied
by both a cast and a comment saying that the conversion is known safe?

I suppose I could think of some coding environments where that might
be appropriate, but not in any professional one. If a programmer
explicitly and clearly tells the compiler to do something, then he
must already think that that's safe. So it's completely redundant.

[...]

But the assignment with a cast and the assignment without a cast
convey exactly the same information to the compiler.

 

[Keith Thompson]

But i++ is inherently safe - at least on most common archtectures. And
certainly there's nothing complicated going on, it is obvious what
happens.

[...]

No, it's not inherently safe.

int i = INT_MAX;
i++;

The "i++" in the above invokes undefined behavior. Perhaps you're
thinking that it will wrap around to INT_MIN, but the standard doesn't
guarantee that.

 

[Doug Mentohl]

No, it's not inherently safe.

int i = INT_MAX;
i++;

The "i++" in the above invokes undefined behavior. Perhaps you're thinking that it will wrap around to INT_MIN, but the standard doesn't guarantee that.

#define INT_MAX sizeof(int) * 8;

 

[Keith Thompson]

#define INT_MAX sizeof(int) * 8;

What?

INT_MAX is a predefined macro in <limits.h>. It expands to a constant
expression whose value is the largest value of type int, at least
32767. sizeof(int) * 8 will give you the size in bits of type int
(*if* CHAR_BIT==8).

What point were you trying to make?

 

[squeamz]

(<OT>C++ did make string literals const; there wasn't as much
concern for maintaining backward compatibility with C.</OT>)

Not True.

 

[Keith Thompson]

Not True.

Would you care to expand on that? If I've made a mistake, I'd like to
have it corrected, but a simple denial is not helpful.

<OT>My copy of a draft of the C++ standard confirms that a C++ string
literal as type "array of n const char".</OT>

 

[David Schwartz]

So what would you recommend when the function to get the size of a
stored object returns a int64_t and the function to process a
configuration object with a max size of 8Kb takes an unsigned?

assert.

-- [mdw]

That's not the issue. The issue is what you do if it fits, not what
you do if it doesn't fit.

If neither the cast nor the implicit conversion are suitable, what is
left?

DS

 

[David Schwartz]

But the assignment with a cast and the assignment without a cast
convey exactly the same information to the compiler.

I agree. But the issue is that they convey different information to a
human or to automated code testing tools.

In a professional coding environment, it's possible the programmer
never considered whether the conversion was safe or not without the
cast. In fact, it's possible that at the time that code was written,
no conversion was necessary and later changes made it necessary.

With the explicit cast, you know the programmer intended the
conversion so at least two possible cases with the implicit conversion
can be ruled out. (Programmer didn't realize there was a conversion
when he wrote the code and no conversion was needed when the code was
written but it became a conversion due to subsequent changes.)

The point is, this catches a decent number of real bugs, so I
recommend it as a professional coding practice. The idea is:

1) All potentially-unsafe conversions should use casts, except where
the cast is so bad as to outweigh the benefit of this rule (see my
examples).

2) A programmer who puts in a cast is vouching for the appropriateness
of that conversion.

3) An auditor who sees a cast can assume the programmer analyzed the
cast and determined it was safe and intended (possibly erroneously, of
course). An auditor who does not see a cast, where the conversion is
not obvious, cannot assume the programmer intended the conversion.

4) Automated testing tools should be used to determine if any
potentially unsafe implicit conversions exist. A reasoned decision
should be made about what to for each one (with a comment in the code,
if appropriate).

5) The ultimate point is to make subtle effects of the code more
obvious so they're not missed at any point in the chain, resulting in
fewer bugs slipping through to audit and fewer bugs passing the code
review process.

DS

 

[David Schwartz]

Nope. What I meant to say was that any explicit cast (in C) should be
accompanied by a comment. After that rule is it up to yourself to
decide when a cast is needed: if you decide to compile with warnings
for lossy conversions, you need to cast - and in that case also to
comment - this is assuming that you sensible require clean compiles.

What does the comment do that the cast doesn't? If you want a comment
like "I have made sure this cast is safe and appropriate", then the
obvious answer is, "of course, that's why I put it there". Programmers
don't explicitly request behavior unless they've made sure it's safe
and appropriate. I see no benefit to a comment there.

If the reason or effects of the cast are not obvious, then sure, a
comment is appropriate. But in many cases, it's quite obvious why the
cast is there. So the comment won't add anything.

I don't really know. You assume of course that the programmer knows
what he's doing, but for those who ned to read the code later the
comment would not be wasted.

I simply assume that the programmer intended the obvious effects of
his code and believes that they are what he wants. I don't think you
have a choice but to assume that.

But i++ is inherently safe - at least on most common archtectures. And
certainly there's nothing complicated going on, it is obvious what
happens.

It's not inherently safe, it can overflow. And if you meant to
subtract one from 'i' rather than add one, who knows what will happen.
The reason for the explicit cast is precisely so that it is obvious
what happens.

If you take a statement such as  y = (T)x; everything gets much more
complicated, and it is not so obvious anymore, at least to me ;-). The
purpose could be to cast away const, it could be to look at a pointer
as an integer value (e.g. for hashing), and it could be to inspect a
structure as raw bytes. It could also be to do stuff, you should not
mention out loud if there's children present,so ill stop right now.
But: lots of options are possible, and the comment would often be
useful.

Sure, if it's useful, put in a comment. But I think in the vast
majority of cases, it's quite obvious.

DS

 

[Antoninus Twink]

Would you care to expand on that? If I've made a mistake, I'd like to
have it corrected, but a simple denial is not helpful.

How times change!

Less than a week has gone by since Keith was saying

I saw at least three minor errors in Stephen's followup -- which is
why redirecting the discussion to comp.unix.programmer is better than
trying to answer it here. I'd be more specific but (a) if I did so it
would inevitably spawn a long off-topic thread, and (b) I could easily
be mistaken myself.

and refused point-blank to describe those errors in this group.

Now when someone points out *his* ignorance on a point, he is perfectly
willing to "spawn a long off-topic thread" to get clarification! And
this time, there's no need to "redirect the discussion to
comp.lang.c++"!

Perhaps all this time hanging around CBF has made some of Falconer's
mind-blowing hypocrisy rub off on Kiki.

 

[Keith Thompson]

But i++ is inherently safe - at least on most common archtectures. And
certainly there's nothing complicated going on, it is obvious what
happens.

[...]

No, it's not inherently safe.

int i = INT_MAX;
i++;

The "i++" in the above invokes undefined behavior. Perhaps you're
thinking that it will wrap around to INT_MIN, but the standard doesn't
guarantee that.

int i = INT_MIN;
i--;

No math is safe. BFD. The subject was casts, conversions and assignment
statements not math. Don't use straw man. Stop deliberately being an ass,
unless of course you are one and want to be treated like one a/k/a a troll.

If you want to killfile me, I certainly won't discourage you.

Somebody said that "i++ is inherently safe". It isn't. I pointed it
out. If you have a problem with that, it's your problem, not mine.