Hi, okay, I think Ticker has some good points here. Reg. my comment "... we can use int even if IMG format uses a single byte, since we don't have huge amounts of header structures." : You can ignore this, I thought about using an int to store the value of a field that is written into e.g. 2 bytes. We often do this because Java returns int when doing calculations e.g. short someFld = 10; int x = 2; someFld /= x; // works someFld = someFld / x; // doesn't compile someFld = (short) (someFld / x); // ok Therefore I prefer to use type int for someFld when I use it for calculations. The explicit type casts are always causing trouble when you change a field from short to int later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Februar 2018 11:52:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] methods to write signed / unsigned integers Hi Gerd The final bit patterns written into the IMG will be the same regardless of using putUx or putSx, but the Garmin device or map renderer will interpret each as either signed or unsigned, depending on where it is in the IMG. If we write, say a value of 200 into a byte, where this is interpreted as a signed by the device, we just have a possibly difficult-to-diagnose map failure. Similarly writing, say, -1, to something that will be interpreted as unsigned will cause a problem. Having different methods with relevant assertions allows these errors to be caught early on. It also clarifies the code. Given that nearly all the int writes in imgfmt are going to be changed, it seems sensible to do it as best as possible. Also, in imgfmt, there is code to read back the IMG structures. This has to known if it should use signed or unsigned read methods. Often, quite close in the code, there will be the output calls for the same items, so having: someFld = reader.get1S(); ...; writer.put1S(someFld) looks difficult to argue with. I don't understand your comment: "... we can use int even if IMG format uses a single byte, since we don't have huge amounts of header structures." It is only during the method call (putxx()) or return (getxx()) that ints will be in use rather than byte/char Regards Ticker On Tue, 2018-02-20 at 09:15 +0000, Gerd Petermann wrote:
Hi Ticker,
please explain why you think that this is important. I like the idea that I don't have to care about the write method, I only have to make sure that the fields can hold the value ranges. In most cases we can use int even if IMG format uses a single byte, since we don't have huge amounts of header structures.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. Februar 2018 10:19:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] methods to write signed / unsigned integers
Hi
I think it is important to indicate if a signed or unsigned is being written so that the range can be asserted:
eg: public void putU1(int val) { assert val >= 0 && val <= 255 : val; buf.put((byte)val); } and public void putS1(int val) { assert val >= -128 && val <= 127 : val; buf.put((byte)val); }
Ticker
On Sun, 2018-02-18 at 21:37 +0000, Steve Ratcliffe wrote:
Hi Gerd, Ticker
For ImgFileWriter I think we should just have put1(int), put2(int), put3(int) and put4(int) and remove put(byte), putChar(char) and putInt(int).
So each method takes an int, so no casting is needed. There is no difference between writing unisigned and signed for any value that fits into an int.
To write unsigned values greater than 2G then technically you need a long, so an unsigned version could be added as a default method on the interface put4u(long val) rather than having to implement across multiple implementations.
Although I don't think it is necessary if you want to add signed/unsigned methods that range check the value, then again add them as default method on the interface.
I've attached a patch that implements this.
Reading is different, we do need signed/unsigned versions. I'd suggest that again have get{1,2,3,4} and remove getChar and getInt special cases, and then get1u() etc for unsigned results. All of these returning int probably, depending on what results in the best looking code. I have not done a patch for that.
..Steve
we have various methods to write an integer with 1, 2, 3, or 4 bytes to an img file. I always feel unsure what method to use because none of them makes clear what happens with negative values.
Besides that some of the existing routines seem to throw misleading exceptions, e.g. FileBackedImgFileWriter seems to assume that it is only used for the mdr tmp file and creates texts like this: throw new MapFailedException("could not write3 to mdr tmp file"); throw new MapFailedException("could not write put3 to mdr tmp file");
Only the javadoc for put1() and put2() tell me the range (0..255 or 0..65535) .
If I got that right put3() allows negative values, so I think it is NOT 0..16777215 but -8388608 .. 8388607 ?
I'd like to improve the readability of the code, but I don't want to mess up anything. Would it be possible to add comments to all the methods?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev