Hide Forgot
This loop in fch_buckets_get_indexes_sorted_by_size in girepository/cmph/fch_buckets.c 186 for(i = (int)buckets->max_size - 1; i >= 0; i--) 187 { 188 sum += value; 189 value = nbuckets_size[i]; 190 nbuckets_size[i] = sum; 191 192 } never exits because the condition i >= 0 is always true; i is declared unsigned: 175 cmph_uint32 i = 0; As a result, the CMPH_FCH code does not work at all.
This has already been fixed upstream, in commit 0c13ae5fa4716e86815d129c1ed88c5fe55cdd44. Some of the other generators are broken as well. The file loaders do not perform sufficient checking and crash on corrupted files. There is a /var/tmp race in brz.c. buffer_entry_read_key and buffer_manager_read_key can write bytes after *keylen, corrupting the stack frame in brz_gen_mphf. All this code isn't used, but still compiled and linked. Let's hope that the code we actually use works better.
(In reply to Florian Weimer from comment #2) > This has already been fixed upstream, in commit > 0c13ae5fa4716e86815d129c1ed88c5fe55cdd44. Yeah...i would have liked to depend on CMPH as a library, but it needed a number of patches, and at the time upstream indicated they might port to C++, which would make the library a lot less interesting for me. Now 3 years later...not sure. It looks like the looming C++ port is now just an experimental additional interface. Filed this as https://bugzilla.gnome.org/show_bug.cgi?id=711622 > Let's hope that the code we actually use works better. The only bits we're using are BDZ. Are there any errors in that?
(In reply to Colin Walters from comment #3) > The only bits we're using are BDZ. Are there any errors in that? It looked better to me (including the generator part). The only risk I see is false negatives during lookups because of some subtle algorithm issue.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.