On Fri, Feb 23, 2018 at 02:46:28PM -0700, Martin Sebor wrote: > > This doesn't address any of my concerns that it is completely random > > what {dst,src}ref->base is, apples and oranges; sometimes it is a pointer > > (e.g. the argument of the function), sometimes the ADDR_EXPR operand, > > sometimes the base of the reference, sometimes again address (if the > > base of the reference is MEM_REF). By the lack of consistency in what > > it is, just deciding on its type whether you take TREE_TYPE or > > TREE_TYPE (TREE_TYPE ()) of it also gives useless result. You could e.g > > call the memcpy etc. function with ADDR_EXPR of a VAR_DECL that has pointer > > type, then if dstref->base is that VAR_DECL, POINTER_TYPE_P (basetype) > > would be true. > > I think I understand what you're saying but this block is only > used for string functions (not for memcpy), and only as a stopgap > to avoid false positives. Being limited to (a subset of) string > functions the case I think you're concerned about, namely calling > strcpy with a pointer to a pointer, shouldn't come up in valid > code. It's not bullet-proof but I don't think there is
Can you explain what is invalid on: char *p; void foo (void) { if (sizeof (p) < 8) return; memcpy (&p, "abcdefg"); strcpy ((char *) &p, (char *) &p + 5); } and similar code? Both memcpy and strcpy are defined as char accesses that can alias anything. If needed tweak it so that you run into this code. Jakub