Thread: [Gpsbabel-code] [PATCH] PCX5
Brought to you by:
robertl
From: Alexander S. <ale...@gm...> - 2004-09-26 18:50:32
Attachments:
gpsb-pcx.diff
pcx5-2.09-variant-dosedited.grm
|
Hello, i am fixing a massive PCX5 reading problem with a single file that i got to my hands. It a) had DOS file endings, b) got a different lat/lon encoding (DEG-Formatcode), c) had shortened lines which lead to massive random chars. As i have seen there are programs around that really can produce PCX5 version 2.00 trough 2.09 on users demand, i do assume that the support for that format in current gpsbabel is far from completeness. My patch is more a work around for at least my specific problem, but a finite solution (including fixes for rather more oddities of PCX5 encoding software, like only 2 digits lon values) would need a nearly total rewrite of that module. Maybe someday when there is need for someone. As of now i would enjoy if you can agree incorporating my patch. I have further attached a stripped version of my input testfile. If you do want to use it with testo, then i dont expect it to be compareable when converted forth and back, but a one way conversion plus a compare would surely work for that file. -Alex. |
From: Robert L. <rob...@us...> - 2004-09-27 01:28:48
|
> file that i got to my hands. It a) had DOS file endings, This should be handled by your C library; those DOS file endings should never make it into the program, right? > b) got a different lat/lon encoding (DEG-Formatcode), yeah, in fantasy land, we'd read the 'H' lines and parse them differently. But as you've seen we don't do that. The premise has been that programs that create PCX seem to be on the edge of extinction so nobody's wanted to incur the complexity of parsing allowing every possibly representable case. > c) had shortened lines which lead to massive random chars. That seems wrong. Did scanf fail? I'd rather just poke the first byte of the buffers to zero than incur a full memset. RJL |
From: Alexander S. <ale...@gm...> - 2004-09-27 19:42:59
|
> > file that i got to my hands. It a) had DOS file endings, > > This should be handled by your C library; those DOS file endings should > never make it into the program, right? C-librays should read in the default format of the platform. But cygwin lets you configure that to either DOS or UNIX. Now ignoring that, there is still the "chance" that i do get a falsely coded file from someone else - i could use recode if i am aware of that but better gpsbabel strips it automatically than producing bogus output files due to trailing <CR>s. > > c) had shortened lines which lead to massive random chars. > > That seems wrong. Did scanf fail? I'd rather just poke the first > byte of the buffers to zero than incur a full memset. Nope it did not fail. (Return values are merely ignored anyways) The input buffer got filled up to the newline, while operations like xstrndup(&ibuf[90], 12); hit uninitialized data. For now the changes do improve the overall likeliness that those file format will get read without fuzz. Maybe i will vest some time to fixup that whole code, but i do not expect me to start earlyer than in the next two weeks. -Alex. |