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.
From: Robert Lipe <robertlipe@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.
From: Alexander Stohr <alexander.stohr@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
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.