https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115436
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2024-06-11
Ever confirmed|0 |1
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this bug.
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?
Otherwise, confirmed with trunk using Compiler Explorer:
https://godbolt.org/z/c3vEYf6do
Looks like
(a) it's not "realizing" that s->cap must be non-zero after the first alloc
(with the caveat about overflow noted above)
(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.
