Hi Gerd / 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

On Fri, 2018-02-23 at 08:03 +0000, Gerd Petermann wrote:
> Hi Steve,
> I think msg.patch looks good. I'd like to postpone the other changes
> until the "shrink factor" in DEM is understood.
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Steve Ratcliffe <st...@parabola.me.uk>
> Gesendet: Mittwoch, 21. Februar 2018 23:40:35
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] methods to write signed / unsigned integers
> Hi
> And here is the patch for just the reading side.
> I decided that it was best to leave in 'byte get()' as there are many
> places where a byte is used to hold the result and a cast would be
> needed for 'int get1()'.
> The tests pass, but there is more scope for getting this patch wrong
> so needs some good testing.
> Also display project would have to be patched to match.
> ..Steve
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list

Reply via email to