https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115436
--- Comment #2 from Branimir Ričko <rickobranimir at gmail dot com> --- ``` I think there *might* be a true positive here for the case where s->cap == 0x80000000, so that s->cap * 2 becomes 0 due to overflow; should my_str_realloc be checking for s->str being null for the "needs malloc" case? ``` Yea, you are right. When I was making the example shorter, I must have made it too short... This should not be affected by overflows: https://godbolt.org/z/dhPcz8Kj4 Analyzer says that on first call to push, *len* is >= *cap*. That means that cap is 0. And then it mallocs on first call. But then it also deduces that on second call *len* can be >= *cap*. This can not be because *cap* was set to 8 on the first call and *len* to 1. ``` (b) there's a definite bug in binding_map, where __analyzer_dump () shows an overlapping concrete binding: clusters within root region cluster for: (*INIT_VAL(s_2(D))) ESCAPED key: {bytes 0-7} value: 'char *' {UNKNOWN(char *)} key: {bytes 0-23} value: 'struct my_str' {UNKNOWN(struct my_str)} key: {bytes 16-23} value: 'unsigned int' {UNKNOWN(unsigned int)} where the binding for bytes 0-23 overlaps that for bytes 0-7. ``` Idk what this is or should be, but to me it looks like `struct my_str` should overlap with `char *`. `struct my_str` is *s and `char *` is `s->str` Or am I missing something?
