> Not it's not, it's hashed as an inode, but the key is a filename, so the > equal function will compare the string pointers.
ahhh, ok. So a) it doesn't work now because its wrong, and b) comparing strings won't actually work either if both paths resolve to the same inode, the hash table will see the hash collide but the strings being different and add it again. So using inode as the hash is just a slow way of making a hash of a file path. In fact Anjuta seems to have made a right hash of the whole thing [pun intended]. Maybe thats why it switched to sqlite for its tags later. > Well, if we used a hash table as a mean of deduping and a list as a mean of > well, building the list, it would not be a problem. Yeah, since 2.40 `g_hash_table_insert()` returns if it inserted or not, so the filename could be added to the list on the fly. But Glib 2.40 didn't exist back when this was originally written. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/1989#issuecomment-436756588
