*p++ = *q++ undefined? why?

[fctk]

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this well
enough.

first of all some terms:
* object = variable, element of an array, location pointed by a pointer
* modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that order):
1) each object in an expression can be modified no more than once;
2) if an object is modified, then all the times that object is accessed
in order to be read, the values that are read must be all used for
calculating the final value of the object.

now give a look at the expression at http://c-faq.com/expr/confused.html
(end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different
pointers p and q [...] are used."

i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).

p, q and *(p++) are modified only once, so they follow rule 1.
*(q++) is not modified, so it also follows rule 1.

p is read only once, and the value of this reading is used for
calculating the final value of p, so rule 2 is respected. the same for
q. *(p++) is never read, so it also respects rule 2.

so, why that expression is undefined?

to be honest, it does not say it is "undefined", but it speaks about
being allowed or not. so: in which case this expression is not allowed?
i can't see when...

also, the compiler (gcc) does not complain as in:

i = i++ /* warning: operation on `i' may be undefined */

so, what's the problem?

[Vladimir S. Oka]

fctk <-> opined:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this
well enough.

first of all some terms:
* object = variable, element of an array, location pointed by a
pointer * modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that
order): 1) each object in an expression can be modified no more than
once; 2) if an object is modified, then all the times that object is
accessed in order to be read, the values that are read must be all
used for calculating the final value of the object.

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Here's the key to understanding this. The assignment is well defined
*only* if `p` and `q` point to different objects in memory. If they
point to the same object you get undefined behaviour.

That is probably the reason for compiler not emitting a diagnostic, as
there are circumstances when above is OK.

Anyway, don't do that.
pointers p and q [...] are used."

i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).

p, q and *(p++) are modified only once, so they follow rule 1.
*(q++) is not modified, so it also follows rule 1.

p is read only once, and the value of this reading is used for
calculating the final value of p, so rule 2 is respected. the same
for q. *(p++) is never read, so it also respects rule 2.

so, why that expression is undefined?

to be honest, it does not say it is "undefined", but it speaks about
being allowed or not. so: in which case this expression is not
allowed? i can't see when...

also, the compiler (gcc) does not complain as in:

i = i++ /* warning: operation on `i' may be undefined */

so, what's the problem?

--
My theology, briefly, is that the universe was dictated but not
signed.
-- Christopher Morley

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

[Charles Krug]

On 2006-04-01, fctk <-> wrote:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this well
enough.

now give a look at the expression at http://c-faq.com/expr/confused.html
(end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different
pointers p and q [...] are used."
i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).
That's not the same expression at all.

i = i++ /* warning: operation on `i' may be undefined */

so, what's the problem?

That's not the same expression as in the FAQ at all.

I'm not certain why you'd ever write code like that, but I can't see
there that expression would create those sorts of problems (IANALL)

[Michael Mair]

fctk schrieb:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this well
enough.

first of all some terms:
* object = variable, element of an array, location pointed by a pointer
* modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that order):
1) each object in an expression can be modified no more than once;
2) if an object is modified, then all the times that object is accessed
in order to be read, the values that are read must be all used for
calculating the final value of the object.

now give a look at the expression at http://c-faq.com/expr/confused.html
(end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different
pointers p and q [...] are used."
There are two possible interpretations:
- p == q is not allowed,
- &p == &q is not allowed, e.g. we must not write
*p++ = *p++

For the following I assume p != 0, q != 0.

i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).
Let us keep this even easier:
p, q, *p, *q
p, q and *(p++) are modified only once, so they follow rule 1.
*(q++) is not modified, so it also follows rule 1.
If p!=q, i.e. p and q point to different objects, then you
could "implement" the above by
1) copying *q to tmp
2) increasing q by one
3) copying p to ptmp
4) increasing p by one
5) copying tmp to *ptmp and "returning" tmp
which we can reorder to 1-3-2-4-5, 1-3-4-2-5, 3-4-1-2-5, 3-1-4-2-5,
3-1-2-4-5 without breaking it.
If we assume p==q, we cannot break this.
Only if we replace "q" by "p", then everything not starting with 1)
and 3) in the first two positions breaks.

p is read only once, and the value of this reading is used for
calculating the final value of p, so rule 2 is respected. the same for
q. *(p++) is never read, so it also respects rule 2.

so, why that expression is undefined?
I guess that the second interpretation is meant.
Reading the whole item 3. from the page implies that "difference"
really is not meant in the sense p != q but in the sense &p != &q.
to be honest, it does not say it is "undefined", but it speaks about
being allowed or not. so: in which case this expression is not allowed?
i can't see when...

also, the compiler (gcc) does not complain as in:

i = i++ /* warning: operation on `i' may be undefined */

so, what's the problem?

HTH
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[fctk]

Charles Krug ha scritto:

On 2006-04-01, fctk <-> wrote:

i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).

That's not the same expression at all.

why *p++ = *q++ is not the same of ((*(p++)) = (*(q++))) ?

[fctk]

Michael Mair ha scritto:

There are two possible interpretations:
- p == q is not allowed,
- &p == &q is not allowed, e.g. we must not write
*p++ = *p++

[...]

I guess that the second interpretation is meant.
Reading the whole item 3. from the page implies that "difference"
really is not meant in the sense p != q but in the sense &p != &q.

of course *p++ = *p++ is undefined, becouse the same object (p) is
modified two times in the same expression, and this is not allowed by
rule 1.

i also made this program:

#include <stdio.h>

int main(void) {

int a[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int *p, *q;

p = q = a;

printf("%d %d %d\n", *p, *q, a[0]);

*(p++) = *(q++);

printf("%d %d %d\n", *p, *q, a[0]);

return 0;

}

and i get the following output (as expected):

0 0 0
1 1 0

i can't really imagine other possible results...

[Michael Mair]

Vladimir S. Oka schrieb:

fctk <-> opined:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this
well enough.

first of all some terms:
* object = variable, element of an array, location pointed by a
pointer * modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that
order): 1) each object in an expression can be modified no more than
once; 2) if an object is modified, then all the times that object is
accessed in order to be read, the values that are read must be all
used for calculating the final value of the object.

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Here's the key to understanding this. The assignment is well defined
*only* if `p` and `q` point to different objects in memory. If they
point to the same object you get undefined behaviour.

Probably I am too coffee-deprived to think clearly but at the moment
I can see nothing but an "a=a" type assignment with side effect free
"a" for this case even with my worst imagination at work...

Cheers
Michael
That is probably the reason for compiler not emitting a diagnostic, as
there are circumstances when above is OK.

Anyway, don't do that.

--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[stathis gotsis]

"fctk" <-> wrote in message
news:44**********************@reader4.news.tin.it. ..

Charles Krug ha scritto:

On 2006-04-01, fctk <-> wrote:

i explain you my reasoning. first of all that expression could be
rewritten as:

((*(p++)) = (*(q++)))

there are 4 objects: p, q, *(p++), *(q++).

That's not the same expression at all.

why *p++ = *q++ is not the same of ((*(p++)) = (*(q++))) ?

I have no idea, they must be the same according to operator precedence.

[pete]

fctk wrote:

Michael Mair ha scritto:

There are two possible interpretations:
- p == q is not allowed,
- &p == &q is not allowed, e.g. we must not write
*p++ = *p++

[...]

I guess that the second interpretation is meant.
Reading the whole item 3. from the page implies that "difference"
really is not meant in the sense p != q but in the sense &p != &q.

of course *p++ = *p++ is undefined, becouse the same object (p) is
modified two times in the same expression,

That's not what you said before:

"p, q and *(p++) are modified only once, so they follow rule 1.
*(q++) is not modified, so it also follows rule 1."

(p) is the operand of a ++ operator
(q) is the operand of a ++ operator
(*p) is the left operand of a = operator
(*q) is the right operand of a = operator

Those 4 expressions refer to 4 different objects.

--
pete

[pete]

Michael Mair wrote:

Vladimir S. Oka schrieb:

fctk <-> opined:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this
well enough.

first of all some terms:
* object = variable, element of an array, location pointed by a
pointer * modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that
order): 1) each object in an expression can be modified no more than
once; 2) if an object is modified, then all the times that object is
accessed in order to be read, the values that are read must be all
used for calculating the final value of the object.

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct,
i.e. only if two different

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Here's the key to understanding this. The assignment is well defined
*only* if `p` and `q` point to different objects in memory. If they
point to the same object you get undefined behaviour.

Probably I am too coffee-deprived to think clearly but at the moment
I can see nothing but an "a=a" type assignment with side effect free
"a" for this case even with my worst imagination at work...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

--
pete

[CBFalconer]

pete wrote:

.... snip ...
As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Assuming p != q.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Eric Sosman]

CBFalconer wrote:

pete wrote:

... snip ...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[fctk]

Vladimir S. Oka ha scritto:

fctk <-> opined:

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct, i.e. only if two different

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Here's the key to understanding this. The assignment is well defined
*only* if `p` and `q` point to different objects in memory. If they
point to the same object you get undefined behaviour.

That is probably the reason for compiler not emitting a diagnostic, as
there are circumstances when above is OK.

Anyway, don't do that.

i can't really understand *why* i get undefined behaviour if `p` and `q`
point to the same object in memory.

[Michael Mair]

pete schrieb:

Michael Mair wrote:

Vladimir S. Oka schrieb:

fctk <-> opined:

hello,

i'm trying to understand what are the rules for determining when an
expression is well defined or not. i found a page
(http://c-faq.com/expr/seqpoints.html) which seems to explain this
well enough.

first of all some terms:
* object = variable, element of an array, location pointed by a
pointer * modification = assignment ( = += ... ), increment/decrement
(postfixed/prefixed)

if i understood correctly, there are two rules (checked in that
order): 1) each object in an expression can be modified no more than
once; 2) if an object is modified, then all the times that object is
accessed in order to be read, the values that are read must be all
used for calculating the final value of the object.

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

i can't understand the following sentence:

"[...] in which three things are modified (p, q, and *p [...]), are
allowed if all three objects are distinct,
i.e. only if two different

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^

Here's the key to understanding this. The assignment is well defined
*only* if `p` and `q` point to different objects in memory. If they
point to the same object you get undefined behaviour.

Probably I am too coffee-deprived to think clearly but at the moment
I can see nothing but an "a=a" type assignment with side effect free
"a" for this case even with my worst imagination at work...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Thank you :-)
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Vladimir S. Oka]

Eric Sosman opined:

CBFalconer wrote:

pete wrote:

... snip ...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Now I can see it as well! Apologies for the confusion.

Now that I actually thought it through, isn't the above the very
construct K&R use to implement `strcpy()`? I left my copy at work, so
I can't look it up, but I'm pretty sure. Along the lines of:

while (*p++ = *q++)
;
--
"I just need enough to tide me over until I need more."
-- Bill Hoest

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

[Chris Torek]

[some snippage; but it starts with:]

fctk <-> opined:

now give a look at the expression at
http://c-faq.com/expr/confused.html (end of point 3):

*p++ = *q++

[and ends with:]

In article <44***********************@reader1.news.tin.it>, fctk <-> wrote:i can't really understand *why* i get undefined behaviour if `p` and `q`
point to the same object in memory.

You do not (get undefined behavior). If p and q are both valid and
both point to some suitable object(s), the statement:

*p++ = *q++

has well-defined behavior, copying the value at *q to the object
named by *p, and incrementing both p and q.

Go back and re-read the web page named above, and look at "point 3"
again. It says that:

*p++ = *q++;

is OK, but:

*p++ = *p++; /* WRONG */

is *not* OK. More precisely, it says:

"... only if two different pointers p and q ... are used"

by which the FAQ means "do not use one single variable, p and p".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Vladimir S. Oka wrote:

Eric Sosman opined:

CBFalconer wrote:

pete wrote:

... snip ...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).
Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Now I can see it as well! Apologies for the confusion.

Now that I actually thought it through, isn't the above the very
construct K&R use to implement `strcpy()`? I left my copy at work, so
I can't look it up, but I'm pretty sure. Along the lines of:

while (*p++ = *q++)
;

Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.

--
pete

[pete]

pete wrote:

Vladimir S. Oka wrote:

Eric Sosman opined:

CBFalconer wrote:
> pete wrote:
>
> ... snip ...
>
>>As long as (*p) is defined and (*q) is defined,
>>there is nothing wrong with (*p++ = *q++).
>
>
> Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Now I can see it as well! Apologies for the confusion.

Now that I actually thought it through, isn't the above the very
construct K&R use to implement `strcpy()`? I left my copy at work, so
I can't look it up, but I'm pretty sure. Along the lines of:

while (*p++ = *q++)
;

Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.

I think instead those examples should be:

char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

though

memmove(1 + char_array, char_array, 1 + strlen(char_array));

would be fine.

--
pete

[Michael Mair]

pete schrieb:

Vladimir S. Oka wrote:

Eric Sosman opined:

CBFalconer wrote:
pete wrote:

... snip ...

>As long as (*p) is defined and (*q) is defined,
>there is nothing wrong with (*p++ = *q++).

Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Now I can see it as well! Apologies for the confusion.

Now that I actually thought it through, isn't the above the very
construct K&R use to implement `strcpy()`? I left my copy at work, so
I can't look it up, but I'm pretty sure. Along the lines of:

while (*p++ = *q++)
;

Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.

Why? How? I cannot see anything undefined in that.
If you wrote "strcpy(char_array + 1, char_array);", then I would
agree.
strcpy() called for overlapping objects invokes UB by both
standards, yes. But the above implementation IMO is safe for
two out of three kinds of overlapping (i.e. t==s and t>s but not
t<s).
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[pete]

Michael Mair wrote:

pete schrieb:

Vladimir S. Oka wrote:

Eric Sosman opined:
CBFalconer wrote:
>pete wrote:
>
>... snip ...
>
>>As long as (*p) is defined and (*q) is defined,
>>there is nothing wrong with (*p++ = *q++).
>
>Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Now I can see it as well! Apologies for the confusion.

Now that I actually thought it through, isn't the above the very
construct K&R use to implement `strcpy()`? I left my copy at work, so
I can't look it up, but I'm pretty sure. Along the lines of:

while (*p++ = *q++)
;

Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.

Why? How? I cannot see anything undefined in that.
If you wrote "strcpy(char_array + 1, char_array);", then I would
agree.

That's what I meant write.

--
pete

[pemo]

pete wrote:

Michael Mair wrote:

pete schrieb:

Vladimir S. Oka wrote:
>Eric Sosman opined:
>>CBFalconer wrote:
>>>pete wrote:
>>>
>>>... snip ...
>>>
>>>>As long as (*p) is defined and (*q) is defined,
>>>>there is nothing wrong with (*p++ = *q++).
>>>
>>>Assuming p != q.
>>
>> Even if p == q. (Confession: I very nearly made
>>the same mistake.)
>
>Now I can see it as well! Apologies for the confusion.
>
>Now that I actually thought it through, isn't the above the very
>construct K&R use to implement `strcpy()`? I left my copy at work, so
>I can't look it up, but I'm pretty sure. Along the lines of:
>
> while (*p++ = *q++)
> ;

Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.

Why? How? I cannot see anything undefined in that.
If you wrote "strcpy(char_array + 1, char_array);", then I would
agree.

That's what I meant write.

I must be going mad, or missing something here - are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}
int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see, the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.

[pete]

pemo wrote:

I must be going mad, or missing something here - are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}

int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see, the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.

When does the 'run' stop?

--
pete

[Joe Wright]

pemo wrote:

pete wrote:

Michael Mair wrote:

pete schrieb:
Vladimir S. Oka wrote:
> Eric Sosman opined:
>> CBFalconer wrote:
>>> pete wrote:
>>>
>>> ... snip ...
>>>
>>>> As long as (*p) is defined and (*q) is defined,
>>>> there is nothing wrong with (*p++ = *q++).
>>> Assuming p != q.
>> Even if p == q. (Confession: I very nearly made
>> the same mistake.)
> Now I can see it as well! Apologies for the confusion.
>
> Now that I actually thought it through, isn't the above the very
> construct K&R use to implement `strcpy()`? I left my copy at work, so
> I can't look it up, but I'm pretty sure. Along the lines of:
>
> while (*p++ = *q++)
> ;
Yes.
/* strcpy: copy t to s; pointer version 3 */
void strcpy(char *s, char *t)
{
while (*s++ = *t++)
;
}

You can see how that implementation of strcpy
would be undefined with something like:

char char_array[] = "xx\0";

strcpy(char_array, char_array + 1);

though

memmove(char_array, char_array + 1, 1 + strlen(char_array + 1));

would be fine.
Why? How? I cannot see anything undefined in that.
If you wrote "strcpy(char_array + 1, char_array);", then I would
agree.

That's what I meant write.

I must be going mad, or missing something here - are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}
int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see, the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.

Because the destination of the assignment is within the source,
corrupting it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

Joe Wright wrote:

pemo wrote:

I must be going mad, or missing something here - are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}
int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see, the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.

Because the destination of the assignment is within the source,
corrupting it.

Specifically, the null characters are being overwritten,
and the loop never ends.

--
pete

[pete]

pete wrote:

Joe Wright wrote:

pemo wrote:

I must be going mad, or missing something here
- are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}
int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see,
the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.

Because the destination of the assignment is within the source,
corrupting it.

Specifically, the null characters are being overwritten,
and the loop never ends.

There's also a reserved identifier problem,
but that's another story.

--
pete

[CBFalconer]

Eric Sosman wrote:

CBFalconer wrote:

pete wrote:

... snip ...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Alright, modify the assumption to:

&p !- &q

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[blufox]

didnt get this part

modify assumption to
&p !- &q
what is wrong in the "!= "?

[stathis gotsis]

"blufox" <pr*************@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

didnt get this part

modify assumption to
&p !- &q
what is wrong in the "!= "?

Quote appropriate context when replying. As to your question, it was just a
typo.

[pete]

CBFalconer wrote:

Eric Sosman wrote:

CBFalconer wrote:

pete wrote:

... snip ...

As long as (*p) is defined and (*q) is defined,
there is nothing wrong with (*p++ = *q++).

Assuming p != q.

Even if p == q. (Confession: I very nearly made
the same mistake.)

Alright, modify the assumption to:

&p !- &q

&p != &q

OK

--
pete

[Bas Wassink]

pete wrote:

pete wrote:

Joe Wright wrote:

pemo wrote:

I must be going mad, or missing something here
- are you saying that
the code below gives UB?

#include <stdio.h>

void strcpy(char *s, char *t)
{
while(*s++ = *t++)
;
}
int main(void)
{
char char_array[] = "xx\0";

strcpy(1 + char_array, char_array);

return 0;
}

If 'yes', can you explain why please.

while(*s++ = *t++)

As far as I can see,
the assignment expression here will 'run' like
this:

1. eval *t

2. take value found in '1' - write to *s

3. increment s then t, OR, increment t then s.

4. repeat.
Because the destination of the assignment is within the source,
corrupting it.

Specifically, the null characters are being overwritten,
and the loop never ends.

There's also a reserved identifier problem,
but that's another story.

From what I can see there's no UB here, since it's not the standard
library function strcpy, which is indeed said to behave undefined if the
objects overlap.
This function is (apart from using a reserved identifier) perfectly
valid. Even swapping the arguments would still make this code valid,
although the behaviour of the function might not be what one would want.

Bas

[Flash Gordon]

Bas Wassink wrote:

pete wrote:

pete wrote:

Joe Wright wrote:

pemo wrote:
> I must be going mad, or missing something here
> - are you saying that
> the code below gives UB?
>
> #include <stdio.h>
>
> void strcpy(char *s, char *t)
> {
> while(*s++ = *t++)
> ;
> }
>
> int main(void)
> {
> char char_array[] = "xx\0";
>
> strcpy(1 + char_array, char_array);
>
> return 0;
> }
<snip>
Because the destination of the assignment is within the source,
corrupting it.
Specifically, the null characters are being overwritten,
and the loop never ends.

There's also a reserved identifier problem,
but that's another story.

From what I can see there's no UB here, since it's not the standard
library function strcpy, which is indeed said to behave undefined if the
objects overlap.
This function is (apart from using a reserved identifier) perfectly
valid. Even swapping the arguments would still make this code valid,
although the behaviour of the function might not be what one would want.

If the overlap is the wrong way round the null termination gets
overwritten so the function does not stop at the end of the array and as
soon as it writes beyond the end of the array it has invoked UB.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[pete]

Bas Wassink wrote:

pete wrote:

There's also a reserved identifier problem,
but that's another story.

From what I can see there's no UB here, since it's not the standard
library function strcpy,
which is indeed said to behave undefined if the
objects overlap.

If a C program defines a function named strcpy,
that cause undefined behavior.
That's what "reserved identifiers" is about.
Renaming the defined function as str_cpy,
would take care of the problem.

--
pete

[pete]

pete wrote:

Bas Wassink wrote:

pete wrote:

There's also a reserved identifier problem,
but that's another story.

From what I can see there's no UB here, since it's not the standard
library function strcpy,
which is indeed said to behave undefined if the
objects overlap.

If a C program defines a function named strcpy,
that cause undefined behavior.
That's what "reserved identifiers" is about.
Renaming the defined function as str_cpy,
would take care of the problem.

After rereading your post,
I see that you acknowledged the reserved identifier problem.
Sorry about that.

Flash Gordon's reply to your post, was right.

--
pete

[pete]

Bas Wassink wrote:

pete wrote:

pete wrote:

Joe Wright wrote:

pemo wrote:

>I must be going mad, or missing something here
>- are you saying that
>the code below gives UB?
>
>#include <stdio.h>
>
>void strcpy(char *s, char *t)
>{
> while(*s++ = *t++)
> ;
>}
>
>
>int main(void)
>{
> char char_array[] = "xx\0";
>
> strcpy(1 + char_array, char_array);
>
> return 0;
>}
>
>If 'yes', can you explain why please.
>
> while(*s++ = *t++)
>
>As far as I can see,
>the assignment expression here will 'run' like
>this:
>
>1. eval *t
>
>2. take value found in '1' - write to *s
>
>3. increment s then t, OR, increment t then s.
>
>4. repeat.
>

Because the destination of the assignment is within the source,
corrupting it.

Specifically, the null characters are being overwritten,
and the loop never ends.

There's also a reserved identifier problem,
but that's another story.

From what I can see there's no UB here, since it's not the standard
library function strcpy,
which is indeed said to behave undefined if the
objects overlap.
This function is (apart from using a reserved identifier) perfectly
valid. Even swapping the arguments would still make this code valid,
although the behaviour of the
function might not be what one would want.

Specifically, the null characters are being overwritten,
and the loop never ends.
The loop attempts to overwrite memory beyond the bounds
of the array, that's undefined behavior.

You can try running the program
if you feel like risking the consequences.
I've noticed that nobody has said
that they've run the program.

--
pete

[Bikram Bhatt]

"pete" <pf*****@mindspring.com> wrote in message
news:44***********@mindspring.com...

pete wrote:

Joe Wright wrote:

>
> pemo wrote:

> > I must be going mad, or missing something here
> > - are you saying that
> > the code below gives UB?
> >
> > #include <stdio.h>
> >
> > void strcpy(char *s, char *t)
> > {
> > while(*s++ = *t++)
> > ;
> > }
> >
> >
> > int main(void)
> > {
> > char char_array[] = "xx\0";
> >
> > strcpy(1 + char_array, char_array);
> >
> > return 0;
> > }
> >
> > If 'yes', can you explain why please.
> >
> > while(*s++ = *t++)
> >
> > As far as I can see,
> > the assignment expression here will 'run' like
> > this:
> >
> > 1. eval *t
> >
> > 2. take value found in '1' - write to *s
> >
> > 3. increment s then t, OR, increment t then s.
> >
> > 4. repeat.
> >
> Because the destination of the assignment is within the source,
> corrupting it.

Specifically, the null characters are being overwritten,
and the loop never ends.

There's also a reserved identifier problem,
but that's another story.

What is that another story ? what is this resreved indentifier problem ?
--
pete

[Bas Wassink]

pete wrote:

pete wrote:

Bas Wassink wrote:

pete wrote:

There's also a reserved identifier problem,
but that's another story.
From what I can see there's no UB here, since it's not the standard
library function strcpy,
which is indeed said to behave undefined if the
objects overlap.

If a C program defines a function named strcpy,
that cause undefined behavior.
That's what "reserved identifiers" is about.
Renaming the defined function as str_cpy,
would take care of the problem.

After rereading your post,
I see that you acknowledged the reserved identifier problem.
Sorry about that.

Flash Gordon's reply to your post, was right.

I realise I overlooked the overwriting of the '\0' at the end of the
string, however, I'm not sure about the reserved identifier problem now,
as the posted program did not include <string.h> and therefore does not
invade the implementations namespace by declaring a function called
'strcpy'.

I know using these standard library function names for personal
functions is a very bad idea, but I can't find anything in K&R2 or the
standard draft that says it's undefined behaviour. But I've probably not
looked hard enough as before..

Bas

[pete]

Bas Wassink wrote:

I know using these standard library function names for personal
functions is a very bad idea, but I can't find anything in K&R2 or the
standard draft that says it's undefined behaviour.
But I've probably not
looked hard enough as before..

Search for these substrings:

"All external names described below are reserved
no matter what headers are included by the program"

"Function names that begin with str"

--
pete

[Micah Cowan]

"Bikram Bhatt" <ex**************@nokia.com> writes:

"pete" <pf*****@mindspring.com> wrote in message
news:44***********@mindspring.com...

There's also a reserved identifier problem,
but that's another story.

What is that another story ? what is this resreved indentifier problem ?

Please include only enough context to be necessary to understand your
reply.

The "reserved identifier problem" pete was referring to was the fact
that you can't just go around defining functions like strcpy() (whose
name is reserved to the implementation).

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[pete]

Bikram Bhatt wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:44***********@mindspring.com...

pete wrote:

Joe Wright wrote:
>
> pemo wrote:

> > I must be going mad, or missing something here
> > - are you saying that
> > the code below gives UB?
> >
> > #include <stdio.h>
> >
> > void strcpy(char *s, char *t)
> > {
> > while(*s++ = *t++)
> > ;
> > }

There's also a reserved identifier problem,
but that's another story.

What is that another story ?
what is this resreved indentifier problem ?

N869
7.1.3 Reserved identifiers

[#2]
If the program declares or defines an identifier
in a context in which it is reserved
(other than as allowed by 7.1.4), or defines a
reserved identifier as a macro name,
the behavior is undefined.

7.26 Future library directions
[#1]
All external names described below
are reserved no matter what headers are included by the
program.

7.26.11 String handling <string.h>
[#1]
Function names that begin with str

I emphasise the "no matter what headers are included" part.

--
pete

[pete]

pete wrote:

Bikram Bhatt wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:44***********@mindspring.com...

pete wrote:
>
> Joe Wright wrote:
> >
> > pemo wrote:
>
> > > I must be going mad, or missing something here
> > > - are you saying that
> > > the code below gives UB?
> > >
> > > #include <stdio.h>
> > >
> > > void strcpy(char *s, char *t)
> > > {
> > > while(*s++ = *t++)
> > > ;
> > > } There's also a reserved identifier problem,
but that's another story.

What is that another story ?
what is this resreved indentifier problem ?

N869
7.1.3 Reserved identifiers

This is probably a better quote:

7.1.3 Reserved identifiers
[#1] Each header declares or defines all identifiers listed
in its associated subclause, and optionally declares or
defines identifiers listed in its associated future library
directions subclause and identifiers which are always
reserved either for any use or for use as file scope
identifiers.
-- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.
-- All identifiers that begin with an underscore are
always reserved for use as identifiers with file scope
in both the ordinary and tag name spaces.
-- Each macro name in any of the following subclauses
(including the future library directions) is reserved
for use as specified if any of its associated headers
is included; unless explicitly stated otherwise (see
7.1.4).
-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.143)

--
pete

[Flash Gordon]

Bas Wassink wrote:

<snip discussion of sample strcpy implementation>

I realise I overlooked the overwriting of the '\0' at the end of the
string, however, I'm not sure about the reserved identifier problem now,
as the posted program did not include <string.h> and therefore does not
invade the implementations namespace by declaring a function called
'strcpy'.

I know using these standard library function names for personal
functions is a very bad idea, but I can't find anything in K&R2 or the
standard draft that says it's undefined behaviour. But I've probably not
looked hard enough as before..

You've not looked hard enough. The identifier is always reserved for
external linkage whether or not the header is included, and the
implementation did not specify static so it was external linkage. From
n1124 section 7.13:
| — All identifiers with external linkage in any of the following
| subclauses (including the future library directions) are always
| reserved for use as identifiers with external linkage.157)
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Bas Wassink]

pete wrote:

Bas Wassink wrote:

I know using these standard library function names for personal
functions is a very bad idea, but I can't find anything in K&R2 or the
standard draft that says it's undefined behaviour.
But I've probably not
looked hard enough as before..

Search for these substrings:

"All external names described below are reserved
no matter what headers are included by the program"

"Function names that begin with str"

Found it: section 7.26 and further.

Both you and Flash Gordon are right.
I really should get me a printed copy of the standard instead of reading
a 550-page pdf draft version on my computer. That'll hopefully save me
from future embarrassment.

Thank you, both of you.

[pete]

Bas Wassink wrote:

I really should get me a printed copy of the standard
I don't know if there is such a thing as a non pdf version
of the standard.

Here's an html c89 draft:
http://rm-f.net/~orange/devel/specif...c89-draft.html

N869, for C99, is in text. I quote that one a lot.
http://www.open-std.org/JTC1/SC22/WG...69/n869.txt.gz
instead of reading
a 550-page pdf draft version on my computer. That'll hopefully save me
from future embarrassment.

Thank you, both of you.

You're welcome.

--
pete

[Mark McIntyre]

On Mon, 03 Apr 2006 18:06:14 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:

Bas Wassink wrote:

I really should get me a printed copy of the standard

I don't know if there is such a thing as a non pdf version
of the standard.

There is - you can spend $200 and buy a paper copy from ANSI or ISO.
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

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 03 Apr 2006 18:06:14 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:

Bas Wassink wrote:

I really should get me a printed copy of the standard

I don't know if there is such a thing as a non pdf version
of the standard.

There is - you can spend $200 and buy a paper copy from ANSI or ISO.

Or you can spend $18 on a pdf copy and print it yourself (which isn't
free, but is likely to cost less than $182).

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

[Richard Bos]

Keith Thompson <ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 03 Apr 2006 18:06:14 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:

Bas Wassink wrote:

I really should get me a printed copy of the standard

I don't know if there is such a thing as a non pdf version
of the standard.

There is - you can spend $200 and buy a paper copy from ANSI or ISO.

Or you can spend $18 on a pdf copy and print it yourself (which isn't
free, but is likely to cost less than $182).

Or you can spend some $50 and buy
<http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470845732.html>,
which includes the Rationale, but not TC2.

Richard

[Mark McIntyre]

On Mon, 03 Apr 2006 22:18:25 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 03 Apr 2006 18:06:14 GMT, in comp.lang.c , pete
<pf*****@mindspring.com> wrote:

Bas Wassink wrote:

I really should get me a printed copy of the standard

I don't know if there is such a thing as a non pdf version
of the standard.

There is - you can spend $200 and buy a paper copy from ANSI or ISO.

Or you can spend $18 on a pdf copy and print it yourself (which isn't
free, but is likely to cost less than $182).

Marvellous. The question was about where to get a /printed/ copy.

--
"I hope, some day, to learn to read.
It seems to be even harder than writing."
--Richard Heathfield

[Ben Pfaff]

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 03 Apr 2006 22:18:25 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:
Or you can spend $18 on a pdf copy and print it yourself (which isn't
free, but is likely to cost less than $182).

Marvellous. The question was about where to get a /printed/ copy.

Printing a copy is a way to get a printed copy.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming

[CBFalconer]

Mark McIntyre wrote:

Keith Thompson <ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

pete <pf*****@mindspring.com> wrote:
Bas Wassink wrote:

> I really should get me a printed copy of the standard

I don't know if there is such a thing as a non pdf version
of the standard.

There is - you can spend $200 and buy a paper copy from ANSI or ISO.

Or you can spend $18 on a pdf copy and print it yourself (which
isn't free, but is likely to cost less than $182).

Marvellous. The question was about where to get a /printed/ copy.

Harrumph - after the action of printing, you /will/ have a printed
copy. If you use something like fineprint in booklet mode you will
even have something with the approximate dimensions of a book.
:-) It will function adequately for enthroned study.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Mark McIntyre]

On Tue, 04 Apr 2006 12:30:33 -0700, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.edu> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Mon, 03 Apr 2006 22:18:25 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:
Or you can spend $18 on a pdf copy and print it yourself (which isn't
free, but is likely to cost less than $182).

Marvellous. The question was about where to get a /printed/ copy.

Printing a copy is a way to get a printed copy.

No, thats a way to print it yourself. Personally I don't regard a
bound, indexed copy of a book printed by a professional company as
equivalent to a stack of a-4 sheets clogging up my printer... :-)

And ICBW but the topic of discussion was that the /printed/ version
may differ from the e-version.
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