[mkgmap-dev] methods to write signed / unsigned integers

Tue Mar 6 23:02:12 GMT 2018

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