Hi Ticker

Sounds good, yes please send the patch.


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


mkgmap-dev mailing list

Reply via email to