Input-line reverser

[Richard Heathfield]

Keith Thompson said:

int i;
i = 42;

The assignment attempts to modify the value of an object, when that
object hasn't been given a value yet.

Ah, I see the problem. Thank you. I was thinking of "modify" in the English
sense of "start with what is already there, and change it somewhat". (The
original was something along the lines of int i; i++; which is clearly an
illegal modification.)

So, mea culpa - the Standardese sense of the word takes precedence (in the
English sense of the word) over the English sense of the word.

 

[Mark McIntyre]

int i;
i = 42;

The assignment attempts to modify the value of an object, when that
object hasn't been given a value yet.

Yes, but this is an assignment, not a modification.

I suspect that RJH and I were both thinking of the usual English usage
of 'modify', as in "I modified the engine of my car" which generally
doesn't mean "I threw away the existing one and replaced it with a
completely different one". If you see my point.
Mark McIntyre

 

[Keith Thompson]

Yes, but this is an assignment, not a modification.

I suspect that RJH and I were both thinking of the usual English usage
of 'modify', as in "I modified the engine of my car" which generally
doesn't mean "I threw away the existing one and replaced it with a
completely different one". If you see my point.

Sure, but i has a value (though an indeterminate one) before the
assignment, which then modifies the existing value. If type int has
no trap representations, the previous value of i is a valid one.

(I'm probably glossing over some subtlety involving undefined
behavior, but I'm too lazy to track down the details in the standard.)

 

[Richard Heathfield]

Keith Thompson said:

Sure, but i has a value (though an indeterminate one) before the
assignment, which then modifies the existing value. If type int has
no trap representations, the previous value of i is a valid one.

I Don't Think So (tm).

Quoth the Standard:

* Undefined behavior --- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-valued objects, for which the Standard imposes no
requirements.

 

[Keith Thompson]

Keith Thompson said:

I Don't Think So (tm).

Quoth the Standard:

* Undefined behavior --- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-valued objects, for which the Standard imposes no
requirements.

And of course one possible consequence of undefined behavior is
assigning a (seemingly) valid value to a variable that hasn't been
explicitly initialized.

Since I've lost track of what the point was supposed to be, I'll leave
it at that.

 

[Richard Heathfield]

Keith Thompson said:

And of course one possible consequence of undefined behavior is
assigning a (seemingly) valid value to a variable that hasn't been
explicitly initialized.

Yes, of course, but that's the weakest argument for "the value is valid"
that I've ever heard. And I suspect you agree!

Since I've lost track of what the point was supposed to be, I'll leave
it at that.

The *original* point was that:

int number;
number++;

is a Bad Thing (tm).

 

[Tim Rentsch]

Keith Thompson said:


I Don't Think So (tm).

Quoth the Standard:

* Undefined behavior --- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-valued objects, for which the Standard imposes no
requirements.

I believe accessing an indeterminate value results
in undefined behavior only if the value can be
a trap representation. If it can't be a trap
representation, the result is only unspecified
behavior, not undefined behavior.

Of course, that doesn't mean it's a good idea,
only that it can't be called undefined behavior
without giving some qualifying premises.

 

[Richard Heathfield]

Tim Rentsch said:

I believe accessing an indeterminate value results
in undefined behavior only if the value can be
a trap representation.

You are thinking of C99, of course. I will worry about that when conforming
compilers become widespread. In C90, the behaviour is undefined.

 

[Tim Rentsch]

Tim Rentsch said:


You are thinking of C99, of course. I will worry about that when conforming
compilers become widespread. In C90, the behaviour is undefined.

I would say that the description in C90 was only poorly worded, not
undefined. Certainly some of the C99 Standard is extensions to the
previous language, but a fair bit of it is simply clarification of
what was intended in C90. The more precise language about the
different kinds of values and identifying trap representations looks
more like a clarification than an extension. Can you name even one
implementation where accessing an object, during its lifetime, using
an unsigned char type ever results in behavior other than loading an
unspecified value?

Besides which, C99 supersedes C90. The community is better served if
C implementations are viewed as not-yet-complete implementations of
C99 rather than as implementations of the now obsolete C90. Anytime
someone in this newsgroup uses a phrase like "Quoth the Standard", it
should be something from the C99 document set that's being quoted.

 

[Richard Heathfield]

Tim Rentsch said:

The community is better served if
C implementations are viewed as not-yet-complete implementations of
C99 rather than as implementations of the now obsolete C90.

The now obsolete C90 is implemented pretty well everywhere. The shiny new
C99 standard is (fully) implemented pretty well nowhere. The community is
best served by a standard that is implemented pretty well everywhere.

 

[Mark McIntyre]

Sure, but i has a value (though an indeterminate one) before the
assignment, which then modifies the existing value.

This is the point we disagree about. In my view, an assignment does
not *modify* the /existing/ value, since it merely overwrites it. It
cares not what the existing value is, and rightly so .

What I'm trying to say is that as far as I'm concerned, modification
*requires* you to examine the existing value.

Mark McIntyre

 

[Keith Thompson]

This is the point we disagree about. In my view, an assignment does
not *modify* the /existing/ value, since it merely overwrites it. It
cares not what the existing value is, and rightly so .

What I'm trying to say is that as far as I'm concerned, modification
*requires* you to examine the existing value.

Then I think you're using the term "modification" in a manner that's
inconsistent with the standard's usage of the term. For example:

int x = 42;
x = 43;

I'd still say that the assignment modifies the value of x, even though
it needn't examine the previous value.

Furthermore, though the standard doesn't (as far as I can tell)
provide a definition for the term "modification", it uses it in a way
that applies to assigning a value to an object even if it wasn't
previously initialized. For example, C99 6.5p2 says:

Between the previous and next sequence point an object shall have
its stored value modified at most once by the evaluation of an
expression.

Clearly the following invokes UB, because both assignments modify the
value of x:
int x = 0;
(x=1) + (x=2);
I beleve the following also invokes UB for the same reason:
int x;
(x=1) + (x=2);

I think the confusion (which I may have started) is in referring to
modifying the *existing* value. The existing value isn't modified;
it's replaced by a different value. In a sense, it's not possible to
modify a value (you can't change the value of 42, you can only produce
a new value that may be based on the value 42). When the standard
talks about modifying the value of x, it means that the value of x
after the modification is different than the value of x before the
modification. (That's not *quite* correct; 3.1p2, a note, says
"Modify" includes the case where the new value being stored is the
same as the previous value.
)

 

[Emmanuel Delahaye]

Albert a écrit :

Could you FIRSTLY tell me why this program crashes?

You forgot 'please'. We are not your slaves...

 

[Emmanuel Delahaye]

Albert a écrit :

I've 'desk-checked' and I still can't figure out why if I enter 'he' it
outputs 'ee'.
Could you give me another hint?

Following the good given advices, I've got this

Hello world !
! dlrow olleH

with this :
<snipped>
How frustrating !

 

[Mike Wahler]

Mike Wahler said:


Indeed, and I did in fact say that "it attempts to modify the
value of an object, when that object hasn't been given a value yet". I'm
still trying to work out what you find objectionable about that.

auto int i;
i++; /* attempts to evaluate (UB) and modify */
i = 1; /* modifies 'i', no UB */

-Mike

 

[Mike Wahler]

Mark McIntyre said:


The modification in question was in fact ++.

But ++ doesn't only modify. First it evaluates. That's the UB.

-Mike

 

[Mark McIntyre]

But ++ doesn't only modify. First it evaluates. That's the UB.

And absolutely nobody still in this thread disagrees. If someone had
not snipped the residue of RJH's original remark (which said 'whose
value has not first been defined' or something similar), this entire
discussion would not be occurring.
Mark McIntyre

 

[Mark McIntyre]

i = 1; /* modifies 'i', no UB */

We have a semantic difference, nothing more. I agree, the value of i
is modified in some sense , but as I've already said, I consider a
modification to be something which makes use of whats already there*.

If you tore down down your house and built a new one, few people
except estate agents would call it a modification of the property.

*IMHO this to is borne out by the etymology of the word, which
dictionary definitions give as deriving from latin 'to measure' and as
often meaning 'to make minor changes'.
Mark McIntyre

 

[Keith Thompson]

We have a semantic difference, nothing more. I agree, the value of i
is modified in some sense , but as I've already said, I consider a
modification to be something which makes use of whats already there*.

But as I pointed out elsewhere in this thread, that's not how the
standard uses the term "modify". Feel free to use your own
definition, but be aware that it's likely to cause confusion.

 

[Mark McIntyre]

But as I pointed out elsewhere in this thread, that's not how the
standard uses the term "modify".

I disagree that the Standard does this.

However I also feel that its insufficiently interesting to pursue, and
consider continuance of this point to be nothing more than a petty
stupidity. There was a confusion about something, I attempted to
clarify where it arose, if someone with too much anality wants to
chase the rabbit, fine with me but don't expect me to play. You say
eether, I say ayther, lets call the whole thing off.

Feel free to use your own
definition, but be aware that it's likely to cause confusion.

I disagree with this too.
Mark McIntyre