Hi Ticker Sounds good, yes please send the patch. Cheers Steve
Starting from Steve's patches (getting.patch, msg.patch and img -write.patch), I've changed mkgmap+test to have/use: int get1s(), get2s(), get3s(), get4() ing get1u(), get2u(), get3u(), getNu() put1s(int), put2s(int), put3s(int), put4(int) put1u(int), put2u(int), put3u(int), putNu(nBytes, int) throughout almost all of imgfmt.
putX{s/u} assert the correct range and the getX{s/u} sign-extend or not as appropriate. assert and sign-extend are meaningless for get4()/put4() so it doesn't have the s/u variants.
In a lot of places I've changed the working variables from byte/char/short to int and avoided any premature range narrowing.
There are a couple of places where I've left byte get() and put(byte) because bit fiddling makes it meaningless to consider the value as a number or I didn't want to touch delicate logic, but generally flags are handled as ints.
I had some problems with test/func/files/GmapsuppTest.java where an empty map leads to negative subdivision width/height and lat/long values bigger than 3 bytes but I've dealt with this.
Something that confused me in imgfmt/app/trergn/TREFileReader.java, around line 118, was the 2*width and 2*height in new SubdivData(... As far as I can see these values have just been read from an .img and so should be written back exactly as they were.
If/when you are interested, I'll send the patch. In the meantime I'm running with it to see if there are any problems
I have a similar patch for Display
Ticker