[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713

Eric Gallager  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-02

--- Comment #3 from Eric Gallager  ---
Confirming due to the link to it from gnulib's manywarnings.m4

[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code

[eggert at cs dot ucla.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713

--- Comment #2 from eggert at cs dot ucla.edu ---
(In reply to David Malcolm from comment #1)

> Am I right in thinking that there's a cast somewhere inside the hash table
> code that at some point casts away the const from the pointer and frees it?

Yes there's a cast to void *, but no it doesn't free the storage. Instead, the
caller later is supposed to take ownership of the storage if it removes the
item from the hashtable, e.g., the caller can later do this:

   void *entry = hash_remove (pattern);
   free (entry);

where ENTRY will be the same pointer as STR in the sample code I gave earlier.
This means there's no leak in addpat per se.

[Bug analyzer/101713] -Wanalyzer-malloc-leak false positive with GNU coreutils hash table code

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101713

--- Comment #1 from David Malcolm  ---
Thanks for reporting this issue.

The analyzer sees that "str" is passed to hash_insert as a const pointer, and
therefore assumes that hash_insert cannot free it, that hash_insert is merely
borrowing a pointer to str, rather than taking ownership.

Am I right in thinking that there's a cast somewhere inside the hash table code
that at some point casts away the const from the pointer and frees it?