| Issue |
122934
|
| Summary |
[TySan] possible false positive with memcpy()?
|
| Labels |
false-positive
|
| Assignees |
|
| Reporter |
seanm
|
I have a TySan report that I think/thought is a false positive. So I used creduce to try and minimize it. It reduced down to the following:
```c
typedef struct {
int a;
int b;
int c;
int i;
int d;
int e;
int f;
int dim[8];
long g
} h;
int k, m = __builtin_object_size(&k, 0);
h b;
void j();
void n(void *o) {
__builtin___memcpy_chk(&k, o, sizeof(0), m);
k; // •••• TySan complains here, line 17
}
void calloc();
h *c = calloc;
void l() {
c->g;
b = *c;
j(0, b);
}
void j(int, void *p) { n(p + 64); }
void main() { l(); }
```
TySan reports:
```
==79752==ERROR: TypeSanitizer: type-aliasing-violation on address 0x000100c1c010 (pc 0x000100c168ec bp 0x00016f1eac30 sp 0x00016f1ea3b0 tid 32786625)
READ of size 4 at 0x000100c1c010 with type int accesses an existing object of type long (in <anonymous type> at offset 64)
#0 0x000100c168e8 in n test-preprocessed.c:17
```
Line 17 looks like it does nothing, but indeed if I comment it out, TySan no longer warns.
This reduced code is pretty nonsensical of course, but in the real code, it's using memcpy() precisely to avoid strict aliasing violations. Isn't memcpy() supposed to be the kosher way to copy anything of any size/alignment to anything else?
Also, and maybe I should make another ticket, but it's a shame the report says:
- `(in <anonymous type> at offset 64)`
instead of:
- `(in 'struct h' at offset 64, field 'g')`
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
