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

Thu Mar 15 10:12:10 GMT 2018

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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <ticker at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img_io_3.patch
Type: application/octet-stream
Size: 157964 bytes
Desc: img_io_3.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180315/3346cc34/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img_io_2.patch
Type: application/octet-stream
Size: 157964 bytes
Desc: img_io_2.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20180315/3346cc34/attachment-0003.obj>