should I use memmove instead of strcpy just to appease valgrind?
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
On Sun, 07 May 2006 14:21:20 +0200 Per Jessen <per@computer.org> 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 <gaf@blu.org> 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 wrote:
On Sun, 07 May 2006 14:21:20 +0200 Per Jessen <per@computer.org> 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
On Sun, 07 May 2006 15:23:58 +0200 Per Jessen <per@computer.org> wrote:
Jerry Feldman wrote:
On Sun, 07 May 2006 14:21:20 +0200 Per Jessen <per@computer.org> 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 <gaf@blu.org> 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, 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
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
On Sun, 07 May 2006 18:16:49 +0200 Per Jessen <per@computer.org> 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 <gaf@blu.org> 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
On Sun, 7 May 2006 09:01:44 -0700 Randall R Schulz <rschulz@sonic.net> 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 <gaf@blu.org> 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
participants (3)
-
Jerry Feldman -
Per Jessen -
Randall R Schulz