
Hi Ticker, sorry, did not find the time to look at it until now. At least for DEM this would not be correct, some values should be written with the signed put versions. I've attached a corrected version of the patch. Besides that I'd prefer not to see comments like // don't think needed: For further testing I'd need the patch for display tool as well. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <ticker@jagIT.co.uk> Gesendet: Mittwoch, 7. März 2018 10:00:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] methods to write signed / unsigned integers Hi Steve / Gerd Here is the main patch Ticker On Tue, 2018-03-06 at 23:02 +0000, Steve Ratcliffe wrote:
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev