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

[Mark Wooding]

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

Assert that it fits; then use an implicit conversion. A cast has no
further explanatory value any more: the assertion tells the reader
everything he needs to know.

-- [mdw]

 

[David Schwartz]

Assert that it fits; then use an implicit conversion.

Except I'm responding to someone who said he didn't like implicit
conversions.

 A cast has no
further explanatory value any more: the assertion tells the reader
everything he needs to know.

No, the cast does three things the implicit conversion does not:

1) It tells the reader that the programmer intended the conversion.
It's not an artifact of later code changes. (Yes, this really does
happen. For example the type of a loop iterator may be changed from
'int' to 'unsigned' without noticing all the places the iterator is
used.)

2) It tells automated testing tools that the conversion is intended.

3) It tells a code reviewer that there is a conversion. The assert
only tells the reviewer that the conversion is safe if the auditor
notices the conversion is there. This is especially important for code
that undergoes bifurcated or multiple levels of review such as
security code, code for gambling devices, code for voting machines,
and so on. Not all the review levels may be thorough enough to notice
the implicit conversion but they still may benefit from knowing the
conversion takes place.

Of course, it's a fair argument how important these three things are.
But there's almost no downside to the cast.

DS

 

[Kenny McCormack]

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.[/QUOTE]

It is well understood by now by everyone that KT is a troll.
But he is a very amusing troll, and no one should consider killfiling him.

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.

Heh heh.

 

[CBFalconer]

Antoninus Twink wrote:
.... nothing of interest ...

Antoninus, I don't think it does much good for you to get upset
about it. I have learned from Keith, and various others on this
news group about C. While I personally wouldn't want to be
acquainted with some of these people, because of their
personalities or attitudes, I don't see why that really matters
when we are all here to learn and share our knowledge.

Why not let the anger pass that you've built up towards Keith?
It's always your choice to take something as an offense, unless
Keith is physically hurting you. To put it another way: if you
were deaf and blind, would you care what Keith had written?

FYI Twink is one of the more notorious trolls on c.l.c. Ignore it.

 

[Guest]

Not True.

which bit?

 

[squeamz]

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>

String literals are used in the exact same way in both languages. The
following line:

char *str = "asdfasdf";

....is valid precisely to maintain backwards-compatibility with C.

 

[Keith Thompson]

String literals are used in the exact same way in both languages. The
following line:

char *str = "asdfasdf";

...is valid precisely to maintain backwards-compatibility with C.

Agreed, but string literals are not "used in the exact same way in
both languages". They are of different types.

Try compiling the following as C and as C++.

char (*p)[8] = &"literal";

 

[squeamz]

String literals are used in the exact same way in both languages.  The
following line:

char *str = "asdfasdf";

...is valid precisely to maintain backwards-compatibility with C.

Agreed, but string literals are not "used in the exact same way in
both languages".  They are of different types.

Try compiling the following as C and as C++.

char (*p)[8] = &"literal";

Huh... I guess I misunderstood what you meant and jumped the gun.
You're right. Sorry about that.

 

[David Schwartz]

one object can have size == 0 (in that address there is not that object)
so condition of error is -1 (routine has wrong) not 0 (caller has wrong)

Either respond to my rebuttal of your argument or don't pretend to.
This example has nothing whatsoever to do with error returns. The zero
return is arbitrary simply to show that the code does not continue if
the conversion is not safe.

DS

 

[Rainer Weikusat]

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.

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined', which, in absence of any
other reason, still rests on 'I am firmly convinced that this
increment is an exceptional occurence, as mentioned in 6.5|5 of the C
standard'. But assuming that the meaning of the post-increment above
isn't defined, the statement that its value will be 'outside the range
of values representable by int' must be wrong: Since the value isn't
defined, it cannot possibly have defined properties.

 

[Flash Gordon]

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.

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined',

From your wording I'm not sure if you realise that the behaviour of the
program (not just the result of the expression) is undefined on
executing that code.

Undefined behaviour has a specific meaning in the C standard.

which, in absence of any
other reason, still rests on 'I am firmly convinced that this
increment is an exceptional occurence, as mentioned in 6.5|5 of the C
standard'. But assuming that the meaning of the post-increment above
isn't defined, the statement that its value will be 'outside the range
of values representable by int' must be wrong: Since the value isn't
defined, it cannot possibly have defined properties.

The standard makes it clear it is talking about what the mathematical
result would be (as opposed to what it would have to be to fit in the
type) by using the word "mathematically" and the phrase "not in the
range of representable values for its type". The full paragraph being:

| If an /exceptional condition/ occurs during the evaluation of an
| expression (that is, if the result is not mathematically deï¬ned or not
| in the range of representable values for its type), the behavior is
| undeï¬ned.

Remember that mathematics exists outside the scope of the limitations of
any particular C implementation.

 

[James Kuyper]

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.

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined', ...

Not really. It's the behavior of the entire program that is undefined,
not just the result. In effect, what this means is that the program can
begin behaving in an unexpected fashion as soon as execution of the
offending statement becomes inevitable; it needn't wait until the
statement is actually executed.

In real life, this means that, among other possibilities, a fully
conforming compiler is allowed to use the fact that i++ would have
undefined behavior if i were to contain INT_MAX, in order to justify
optimizations based upon the assumption that the value of 'i' at that
point is not INT_MAX. Those optimizations could cause the program to
start misbehaving much earlier than the point where i++ would be executed.

I'm not fond of the "invoked" terminology - but it does carry a
connotation of magic, which is helpful when you consider just how
bizarre the possibilities (and real-world actualities, for that matter)
are that are permitted by the standard, once it declares that the
behavior is undefined.

... which, in absence of any
other reason, still rests on 'I am firmly convinced that this
increment is an exceptional occurence, as mentioned in 6.5|5 of the C
standard'. But assuming that the meaning of the post-increment above
isn't defined, the statement that its value will be 'outside the range
of values representable by int' must be wrong: Since the value isn't
defined, it cannot possibly have defined properties.

Luckily, it's the behavior that's undefined, not the value. The value
that would be the result of that expression if it had defined behavior
is INT_MAX+1, interpreted mathematically; that remains true even though
the fact that it is out of range renders the behavior undefined.

 

[Rainer Weikusat]

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

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined',

From your wording I'm not sure if you realise that the behaviour of
the program (not just the result of the expression) is undefined on
executing that code.

Since one is a necessary consequence of the other, a claim like the
one above doesn't make much sense (and it is somewhat out-of-context
here, because the topic was the behaviour of this expression).

Undefined behaviour has a specific meaning in the C standard.

If this was so, it would be (some) defined behaviour. 'Undefined
behaviour' may 'invoke' particular associations in your mind, but
insofar the C standard is concerned, it is just 'behaviour for which
this ... standard imposes no requirements', which is the absence of
any specified meaning.

The standard makes it clear it is talking about what the mathematical
result would be (as opposed to what it would have to be to fit in the
type) by using the word "mathematically" and the phrase "not in the
range of representable values for its type". The full paragraph being:

| If an /exceptional condition/ occurs during the evaluation of an
| expression (that is, if the result is not mathematically deï¬ned or not
| in the range of representable values for its type), the behavior is
| undeï¬ned.

The phrase used is 'not mathematically defined'. The obvious example
would be x/0, x != 0. But that's the first example and not the second,
and the 'mathematical value' crept in here - alas, dark spectures of
our guilty conscience! - because it is mentioned alongside the
conversion rules you want to ignore ...

 

[Flash Gordon]

[...]
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.
'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined',

From your wording I'm not sure if you realise that the behaviour of
the program (not just the result of the expression) is undefined on
executing that code.

Since one is a necessary consequence of the other, a claim like the
one above doesn't make much sense (and it is somewhat out-of-context
here, because the topic was the behaviour of this expression).

Wrong. The behaviour on that expression being executed could be that the
program crashes, rather than that it returns a value.

If this was so, it would be (some) defined behaviour. 'Undefined
behaviour' may 'invoke' particular associations in your mind, but
insofar the C standard is concerned, it is just 'behaviour for which
this ... standard imposes no requirements', which is the absence of
any specified meaning.

Yes, which *is* a specific meaning, and includes possibilities where the
expression does not produce ANY value. How does that expression produce
an undefined value if the compiler refuses to compile the program (which
it is specifically allowed to do) or if the program crashes before that
expression is fully evaluated?

The phrase used is 'not mathematically defined'. The obvious example
would be x/0, x != 0. But that's the first example and not the second,
and the 'mathematical value' crept in here - alas, dark spectures of
our guilty conscience! - because it is mentioned alongside the
conversion rules you want to ignore ...

Conversion rules have nothing to do with the code above since the
variable is of type int.

Also I explicitly pointed out the second clause, "not in the range of
representable values for its type" which could only possibly make sense
if it is talking about the value that the expression would have if the
range was not limited, i.e. the mathematical result of the expression.

There are two options that I can see, one is that the paragraph is
nonsense and the other is that the paragraph has the obvious meaning.
You seem to want the interpretation that the paragraph is nonsense.

 

[Antoninus Twink]

Antoninus, I don't think it does much good for you to get upset about
it. I have learned from Keith, and various others on this news group
about C. While I personally wouldn't want to be acquainted with some
of these people, because of their personalities or attitudes, I don't
see why that really matters when we are all here to learn and share
our knowledge.

I think you make a valid point. I do try my best to make sure that any
criticisms I make of the vested interests in this group are heavily
outweighed by my positive answers to questions, but sometimes
frustration wins the day.

I also welcome Keith's technical contributions to this group - my only
beef with him is that he feels the need to try to constrain other
people's discussions.

I am very happy here and now to declare a "truce", and pledge not to be
the first one to write anything insulting or offensive about Thomson,
Heathfield or any of the others, until they insult me first. Feel free
to flag up any post of mine that you regard as offensive, and I'll point
you to the post (timestamped later than this one: 2009-04-13, 16:10 UTC)
where they began the insults. And from then on, let no one say that the
"trolls" are the ones who make the trouble.

I have to say that I am not optimistic (Han tried something similar with
Heathfield a while back, and it took Heathfield only a couple of hours
to post something gratuitously insulting), but I will give it a go in
good faith.

[For the avoidance of doubt, I don't regard the plain statement of fact
that there are differing views of topicality in clc as an insult.
However, language like "troll" on the one side, or "autistic pedant" on
the other side, is offensive.]

 

[Rainer Weikusat]

Rainer Weikusat wrote:
[...]
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.
'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined',
From your wording I'm not sure if you realise that the behaviour of
the program (not just the result of the expression) is undefined on
executing that code.

Since one is a necessary consequence of the other, a claim like the
one above doesn't make much sense (and it is somewhat out-of-context
here, because the topic was the behaviour of this expression).

Wrong.

What topics I am discussing is up to me, not up to you (I know that's
not what you would like the 'wrong' to have applied to, but since that
doesn't make any sense anyway, I have chosen to interpret it sensibly).

The behaviour on that expression being executed could be that
the program crashes, rather than that it returns a value.

I wasn't writing about what might or might not happen when code
generated from input source code without a defined meaning would be
executed. It useless to speculate about that, anyway.

Yes, which *is* a specific meaning,

No, it is the absence of anything specific. That's why it is called
_UN_DEFINED.

[...]

Conversion rules have nothing to do with the code above since the
variable is of type int. Also I explicitly pointed out the second
clause, "not in the range of representable values for its type"

But you wrongly connected the 'mathematical' from the first clause
with the second, alluding to 'the mathematical value of the expression',
this being a term used in footnote 49, which is an explanation of how
to convert a 'large' value to a 'small' unsigned integer type.

Not that any of this would anyhow relate to my original statement
about how an expressioned claimed to have undefined behaviour could be
defined to have a value which causes the behaviour to be undefined
without - well - not having undefined behaviour.

 

[Rainer Weikusat]

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

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined', ...

Not really. It's the behavior of the entire program that is undefined,
not just the result.

You can subtitutes 'the consequences of' instead of 'the result of' if
you happen to like that better. This may be a Germanism.

[...]

I'm not fond of the "invoked" terminology - but it does carry a
connotation of magic,

But 'absence of information about X' is nothing magical.

[...]

Luckily, it's the behavior that's undefined, not the value.

If the behaviour is undefined, the value of the expression cannot be
defined, since there need not even be any value, let alone a
particular value. Hence, no particular value can be assumed as a
reason why the behaviour would be undefined and this includes any
particular internal value.

 

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

'Undefined behaviour' cannot be 'invoked'. The correct statement would
be 'I [meaning you] have no idea what will happen because of that'. A
reason why this would be so could be that 'the result of evaluating
this particular expression is undefined', which, in absence of any
other reason, still rests on 'I am firmly convinced that this
increment is an exceptional occurence, as mentioned in 6.5|5 of the C
standard'. But assuming that the meaning of the post-increment above
isn't defined, the statement that its value will be 'outside the range
of values representable by int' must be wrong: Since the value isn't
defined, it cannot possibly have defined properties.

We often use the phrase "foo invokes undefined behavior" to mean "the
behavior of foo is undefined". Personally, I find the meaning clear
enough, but I'll rephrase it if you prefer.

The behavior of "i++" in the above is undefined.

 

[Keith Thompson]

If this was so, it would be (some) defined behaviour. 'Undefined
behaviour' may 'invoke' particular associations in your mind, but
insofar the C standard is concerned, it is just 'behaviour for which
this ... standard imposes no requirements', which is the absence of
any specified meaning.

[...]

I'm sure that he meant that the *phrase* "undefined behavior" has a
specific meaning in the C standard -- a meaning that you quoted
yourself.

 

[Richard Tobin]

Can anyone here mention an architecture which crashed and did not wrap?

I don't know of any, but I do know that some compilers now *assume*
that overflow does not occur, and so do optimisations inconsistent
with wrapping.

[In general, I'm unconvinced about the benefit of many of these
optimisations; the basis for them it that if overflow (or whatever)
does occur, then the behaviour is undefined, so it doesn't matter that
they produce the "wrong" answer. But in many cases what they are
actually detecting is a bug in the program. There should at least be
a switch to warn whenever such an optimisation is done, so that the
user can check that it's not the result of a mistake.]

-- Richard