why do strcpy, strcat, & co return a pointer ?

[Barry Schwarz]

Barry Schwarz wrote:

It allows you to be baffled by the peculiar run-time actions of:

char p[100] = "Fred";
....
printf("%s or %s\n", p, strcat(p, " and George"));

That code has undefined behavior, you know.

Is it really undefined since there are implied sequence points at the
call to and return from strcat and p is only modified within strcat.

In fact p is never modified. The storage at which p points IS
modified. Thus the action is well defined, but unexpected. I
think this is one of the few mistakes Ben has made.

p is an array and not a pointer so p is being modified.

Yes, but it is modified between two well defined sequence points: the
one preceding the strcat call and the one preceding its return.

No undefined behaviour at all.

Since Ben didn't identify why he thought it was undefined behavior,
I'm still waiting for him to chime in.

To say what? That he goofed?

Possibly; it wouldn't be the first time for most of us. Or maybe to
indicate he was thinking of something else.


<<Remove the del for email>>

 

[Irrwahn Grausewitz]

Non-modifiable lvalues cannot be modified by an assignment statement
but arrays are objects and certainly can be modified. In fact, after
strcat returns, the contents of the array p have been modified.

Agreed.

Regards,

 

[Dan Pop]

Well, right. And since the changes to the object designated by p
are completed before pointers to the first byte of that object are
passed to printf, the construct in question upthread is well defined
in terms of C.

This was also my conclusion, posted higher upthread. The change to the
value of the p object is delimited by two well defined sequence points.

Dan

 

[Dan Pop]

Barry Schwarz wrote:

It allows you to be baffled by the peculiar run-time actions of:

char p[100] = "Fred";
....
printf("%s or %s\n", p, strcat(p, " and George"));

That code has undefined behavior, you know.

Is it really undefined since there are implied sequence points at the
call to and return from strcat and p is only modified within strcat.

In fact p is never modified. The storage at which p points IS
modified. Thus the action is well defined, but unexpected. I
think this is one of the few mistakes Ben has made.

p is an array and not a pointer so p is being modified.

Yes, but it is modified between two well defined sequence points: the
one preceding the strcat call and the one preceding its return.

No undefined behaviour at all.

Since Ben didn't identify why he thought it was undefined behavior,
I'm still waiting for him to chime in.

To say what? That he goofed?

Possibly; it wouldn't be the first time for most of us. Or maybe to
indicate he was thinking of something else.

Is there anything else to think about as a source of undefined behaviour?

Dan

 

[Irrwahn Grausewitz]

This was also my conclusion, posted higher upthread. The change to the
value of the p object is delimited by two well defined sequence points.

Which is what I tried to express (possibly using inapproriate terms)
just before you chimed in. Seems that we entirely agree now.

Regards