logo separator

[mkgmap-dev] [mkgmap-svn] Commit r4854: - fix possible error when negativ index was written to lookup table

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Jan 10 19:16:51 GMT 2022

Hi Ticker,

table1 size depends on the number of levels with values and the existence of the lookup table, empty levels are not stored.
When there is a lookup table (table2) we must not store the corresponding top 5 /6 levels in table1.

I don't understand the part after "Should it need ..." . It worked in my tests but of course I might have missed a special case.
It's all work in progress. I plan to add unit tests, something like "given these frequencies and codepage xyz the result should look like ...".

I plan to recode MdrDisplay now that I undestand almost all data.
I also want to implement this in MdrCheck during the next days.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 10. Januar 2022 17:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4854: - fix possible error when negativ index was written to lookup table

Hi Gerd

More minor stuff - Still haven't understood the mincode parts


loopupBits/lookupBits is very confusing.
Can you have lookupBits for table2 size and something else for table1

If maxDepth < initial size (5 or 6), can't you just set table1 size to
maxDepth and set table2 size to 0. Or did you find this combination
didn't work.

Should it need:
        while (pos >= 0) {
                tab2[pos * 2] = 0;
                tab2[pos * 2 + 1] = (byte) lastIndex;
Won't the data have been exhausted, with v0 being the first index of
table1 (0) and v2 correct

would be clearer to spot/remember the bottom bit flag in table2, and
>>1 the data in both cases, then present the char data as numBits/char
and the non-char data as minLev/maxLev


mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list