«

Keith Thompson said:

> Richard Heathfield <> writes:
>>
>> 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.
>
> 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.

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

On Sat, 31 Dec 2005 06:47:32 GMT, in comp.lang.c , Keith Thompson
<kst-> wrote:

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

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mark McIntyre <> writes:
> On Sat, 31 Dec 2005 06:47:32 GMT, in comp.lang.c , Keith Thompson
> <kst-> wrote:
>>
>>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.

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

--
Keith Thompson (The_Other_Keith) kst- <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 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.


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

Richard Heathfield <> writes:
> 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.

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.

--
Keith Thompson (The_Other_Keith) kst- <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 said:

> Richard Heathfield <> writes:
>> 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.
>
> 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).


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

Richard Heathfield <> writes:

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

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.

Tim Rentsch said:

> Richard Heathfield <> writes:
>
>> 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.
>
> 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.

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

Richard Heathfield <> writes:

> Tim Rentsch said:
>
> > Richard Heathfield <> writes:
> >
> >> 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.
> >
> > 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.

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.

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.

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