should I use memmove instead of strcpy just to appease valgrind?

newer
SPAM: Question About Driver Update...

Per Jessen

7 May 2006 7 May '06

12:21

valgrind always complains about overlapping strcpy()s, even when the src-address is clearly > dst-address. I know the strcpy manpage says the operands may not overlap, but surely an overlap where src>dst is still ok? Why is valgrind unhappy about it? /Per Jessen, Zürich

Show replies by date

Jerry Feldman

7 May 7 May

12:51

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

On Sun, 07 May 2006 14:21:20 +0200 Per Jessen wrote:

...

valgrind always complains about overlapping strcpy()s, even when the src-address is clearly > dst-address. I know the strcpy manpage says the operands may not overlap, but surely an overlap where src>dst is still ok? Why is valgrind unhappy about it? It does not matter if src < dst or dst < src. What matters is that dst does not lie anywhere in src, or vice versa.

Many times, in string processing I have had situations like: char *dst = "abcd": char *src = dst + 2; strcpy(dst, src); In this case the result will be "cd". But, there is also an overlap. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Per Jessen

13:23

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

Jerry Feldman wrote:

...

On Sun, 07 May 2006 14:21:20 +0200 Per Jessen wrote:

...
valgrind always complains about overlapping strcpy()s, even when the src-address is clearly > dst-address. I know the strcpy manpage says the operands may not overlap, but surely an overlap where src>dst is still ok? Why is valgrind unhappy about it?

It does not matter if src < dst or dst < src. What matters is that dst does not lie anywhere in src, or vice versa.

Can you elaborate on that, in particular why src cannot lie anywhere in dst. If I was programming assembler, that's a perfectly valid MOV.

...

Many times, in string processing I have had situations like: char *dst = "abcd": char *src = dst + 2; strcpy(dst, src); In this case the result will be "cd". But, there is also an overlap.

That's the situation that valgrind complains about. Using a memmove() instead of strcpy() in this example would seem like overkill? /Per Jessen, Zürich

Jerry Feldman

14:00

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

On Sun, 07 May 2006 15:23:58 +0200 Per Jessen wrote:

...

Jerry Feldman wrote:

...
On Sun, 07 May 2006 14:21:20 +0200 Per Jessen wrote:

...
valgrind always complains about overlapping strcpy()s, even when the src-address is clearly > dst-address. I know the strcpy manpage says the operands may not overlap, but surely an overlap where src>dst is still ok? Why is valgrind unhappy about it?

It does not matter if src < dst or dst < src. What matters is that dst does not lie anywhere in src, or vice versa.

Can you elaborate on that, in particular why src cannot lie anywhere in dst. If I was programming assembler, that's a perfectly valid MOV.

...
Many times, in string processing I have had situations like: char *dst = "abcd": char *src = dst + 2; strcpy(dst, src); In this case the result will be "cd". But, there is also an overlap.

That's the situation that valgrind complains about. Using a memmove() instead of strcpy() in this example would seem like overkill? The bottom line is that src and dst overlap and do violate the strcpy(3) rule. If you know what you are doing, fine. strncpy(dst, src, 2); In this case, the strings do not overlap, but valgrind may still complain if it uses strlen(src).

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Randall R Schulz

16:01

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

Per, On Sunday 07 May 2006 06:23, Per Jessen wrote:

...

...

Can you elaborate on that, in particular why src cannot lie anywhere in dst. If I was programming assembler, that's a perfectly valid MOV.

There is no guarantee on the order in which source characters are copied to the destination.

...

...

/Per Jessen, Zürich

Randall Schulz

Per Jessen

16:16

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

Randall R Schulz wrote:

...

On Sunday 07 May 2006 06:23, Per Jessen wrote:

...
...

Can you elaborate on that, in particular why src cannot lie anywhere in dst. If I was programming assembler, that's a perfectly valid MOV.

There is no guarantee on the order in which source characters are copied to the destination.

Interesting. I guess I had assumed a left-to-right sequence, but perhaps with out-of-order execution ... So would you use memmove() in the otherwise perfectly normal case of strcpy(a, a+2)? It still looks like overkill to me, but if the copying is not guaranted to be in order, well. /Per Jessen, Zürich

Jerry Feldman

23:33

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

On Sun, 07 May 2006 18:16:49 +0200 Per Jessen wrote:

...

So would you use memmove() in the otherwise perfectly normal case of strcpy(a, a+2)? It still looks like overkill to me, but if the copying is not guaranted to be in order, well. You are probably save, but not guaranteed. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

Jerry Feldman

23:32

New subject: [suse-programming-e] should I use memmove instead of strcpy just to appease valgrind?

On Sun, 7 May 2006 09:01:44 -0700 Randall R Schulz wrote:

...

There is no guarantee on the order in which source characters are copied to the destination. This also may be more true in 64-bit systems where the copy may be implemented by reading 8 bytes at a time. Some optimized compilers do generate some very weird inline code.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

6561

Age (days ago)

6561

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Jerry Feldman
Per Jessen
Randall R Schulz