[Gpsbabel-code] [Gpsbabel-misc] Problems converting Garmin custom waypoint symbol names

[Robert Lipe]

Opening note: If you're a dabbler in programming, there's about a dozen
independent projects laid out below. Each is small - most are a dozens of
lines of code or less and we could use a hand with more contributors in the
code.



adding gpsbabel-code for the bitslingers.
gpsbabel-misc -> bcc for closure on that list.

checking for random stuff to make you feel better... failed
I'm not at all sure what to make of it.

It means I had a theory that nobody ever read that giant wall of text.
You're like the third person in ~15 years and millions of downloads to
notice it. :-)


The other warnings originated from the compiler. Apart from "sign-com-

pare" type warnings I got plenty of "unused-but-set-variable" (and it's
a bit enervating to read about set but unused variables like "lat" and
"lon" in a GPS program), a few "char-subscripts", two "array-bounds" and

I checked in r5002 that cleans up a lot of these. All were benign. It's
pretty common in code that reads disk files to have to read some bytes and
have some idea what they are but not need them. It's handy to give them a
name. The lat/lon cases were all of the form.

lat = read_N_bytes();
lon = read_N_bytes();
something_important = read_N_bytes()
#if DEBUG
print something_important about lat/lon
#endif

...we have to read those bytes, but if we're not debugging, we don't DO
anything with them. "fixed" by decorating (void).


one "comment" type warning (not sure whether or not these only show up

under Cygwin, so I'll go into the trouble of listing them all here).

It looks like GCC 4.8 has added a bunch of hyperactive warnings to -Wall.
We should probably turn these off unless someone else wants to do the work
of cleaning these up. I've ripped through the mechanical ones and fixed
them, but I'll scribble notes on the remaining ones that actually need some
thought in the hope that it helps budding Bablers tackle small projects.
(I think I'm traveling 3 of the next 4 weeks...)

route.cc: In function ‘void track_recompute(const route_head*,
route.cc:664:84: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
if (thisw->GetCreationTime().isValid() &&
(thisw->GetCreationTime().toTime_t() < tdata->start)) {
^
route.cc:668:41: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
if (thisw->creation_time.toTime_t() > tdata->end) {

route.cc should quit using toTime_t. tdata needs to use appropriate data
types.

strptime.c:302:5: warning: array subscript has type ‘char’
[-Wchar-subscripts]
if (isspace(*fmt)) {
^
strptime.c:303:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:520:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:289:21: warning: variable ‘era’ set but not used
[-Wunused-but-set-variable]
struct era_entry *era;
^
strptime.c:277:15: warning: variable ‘rp_backup’ set but not used
[-Wunused-but-set-variable]
const char *rp_backup;

Should look for an update version of strptime from upstream. Better yet,
find remaining uses of strptime and replace them with QDateTime methods.
Unfortunately, we may have to keep strptime for csv_util because we expose
them in the csv files and the Qt format strings aren't QUITE the same as
the strptime. (Frankly, if it was the only remaining use, I'd go fix our
own style files and remove strptime and just say that's the new scheme...)

jeeps/gpsapp.cc:1682:18: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (gps_time != 0xffffffff && gps_time != 0) {

Cast it or make the constant U ?


jeeps/gpscom.cc: In function ‘int32 GPS_Command_Send_Course(const char*,

GPS_SCourse**, GPS_SCourse_Lap**, GPS_STrack**, GPS_SCourse_Point**, int32,
jeeps/gpscom.cc:806:13: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (n_crs > limits.max_courses
^
jeeps/gpscom.cc:807:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_clp > limits.max_course_laps
^
jeeps/gpscom.cc:808:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_trk > limits.max_course_trk_pnt
^
jeeps/gpscom.cc:809:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_cpt > limits.max_course_pnt) {

This is Gerhard's course stuff; I'm not sure we ever even actually use it.
Maybe we should compile that course stuff away totally.

Meta Grouchiness about Jeeps: Can'd decide between CamelCase and
underbar_separators? Why not BOTH!

t has type ‘char’ [-Wchar-subscripts]

magproto.cc:750:35: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (current_time().toTime_t() > later) {

Should quit using Time_t. Fix the type for 'later'.

nmea.cc:678:8: warning: variable ‘scn’ set but not used
[-Wunused-but-set-variable]
int scn,cnt;

This was about the only one that indicated an actual bug. Fixed. (weakly)

...
For

now,

adding || defined (__CYGWIN__) to that list probably works. Probably.

Bingo! That DOES in fact work!

That should probably be solved "better", but for now, I've added that just
to remove the obstacle for any Cygwin users in the audience. A better fix
would test for the foo64() functions in configure and set the existing
IOAPI_NO_64
manifest and remove my hack.

[tsteven4]

I am still nervous about zlib after our troubles in the recent past.
Does r5003 work with 32 bit cygwin and 64 bit cygwin? I don't remember
the trouble that led to r4824, but I don't relish going down that path
again.

Post by Robert Lipe
Opening note: If you're a dabbler in programming, there's about a
dozen independent projects laid out below. Each is small - most are a
dozens of lines of code or less and we could use a hand with more
contributors in the code.
adding gpsbabel-code for the bitslingers.
gpsbabel-misc -> bcc for closure on that list.
checking for random stuff to make you feel better... failed
I'm not at all sure what to make of it.
It means I had a theory that nobody ever read that giant wall of
text. You're like the third person in ~15 years and millions of
downloads to notice it. :-)
The other warnings originated from the compiler. Apart from "sign-com-
pare" type warnings I got plenty of "unused-but-set-variable" (and
it's
a bit enervating to read about set but unused variables like
"lat" and
"lon" in a GPS program), a few "char-subscripts", two
"array-bounds" and
I checked in r5002 that cleans up a lot of these. All were benign.
It's pretty common in code that reads disk files to have to read some
bytes and have some idea what they are but not need them. It's handy
to give them a name. The lat/lon cases were all of the form.
lat = read_N_bytes();
lon = read_N_bytes();
something_important = read_N_bytes()
#if DEBUG
print something_important about lat/lon
#endif
...we have to read those bytes, but if we're not debugging, we don't
DO anything with them. "fixed" by decorating (void).
one "comment" type warning (not sure whether or not these only show up
under Cygwin, so I'll go into the trouble of listing them all here).
It looks like GCC 4.8 has added a bunch of hyperactive warnings to
-Wall. We should probably turn these off unless someone else wants to
do the work of cleaning these up. I've ripped through the mechanical
ones and fixed them, but I'll scribble notes on the remaining ones
that actually need some thought in the hope that it helps budding
Bablers tackle small projects. (I think I'm traveling 3 of the next 4
weeks...)
route.cc: In function ‘void track_recompute(const route_head*,
route.cc:664:84: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (thisw->GetCreationTime().isValid() &&
(thisw->GetCreationTime().toTime_t() < tdata->start)) {
^
route.cc:668:41: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (thisw->creation_time.toTime_t() > tdata->end) {
route.cc should quit using toTime_t. tdata needs to use appropriate
data types.
strptime.c:302:5: warning: array subscript has type ‘char’
[-Wchar-subscripts]
if (isspace(*fmt)) {
^
strptime.c:303:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:520:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:289:21: warning: variable ‘era’ set but not used
[-Wunused-but-set-variable]
struct era_entry *era;
^
strptime.c:277:15: warning: variable ‘rp_backup’ set but not used
[-Wunused-but-set-variable]
const char *rp_backup;
Should look for an update version of strptime from upstream. Better
yet, find remaining uses of strptime and replace them with QDateTime
methods. Unfortunately, we may have to keep strptime for csv_util
because we expose them in the csv files and the Qt format strings
aren't QUITE the same as the strptime. (Frankly, if it was the only
remaining use, I'd go fix our own style files and remove strptime and
just say that's the new scheme...)
jeeps/gpsapp.cc: In function ‘void GPS_D109_Get(GPS_SWay**, UC*,
jeeps/gpsapp.cc:1682:18: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (gps_time != 0xffffffff && gps_time != 0) {
Cast it or make the constant U ?
jeeps/gpscom.cc: In function ‘int32 GPS_Command_Send_Course(const
char*, GPS_SCourse**, GPS_SCourse_Lap**, GPS_STrack**,
jeeps/gpscom.cc:806:13: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (n_crs > limits.max_courses
^
jeeps/gpscom.cc:807:16: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
|| n_clp > limits.max_course_laps
^
jeeps/gpscom.cc:808:16: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
|| n_trk > limits.max_course_trk_pnt
^
jeeps/gpscom.cc:809:16: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
|| n_cpt > limits.max_course_pnt) {
This is Gerhard's course stuff; I'm not sure we ever even actually use
it. Maybe we should compile that course stuff away totally.
Meta Grouchiness about Jeeps: Can'd decide between CamelCase and
underbar_separators? Why not BOTH!
t has type ‘char’ [-Wchar-subscripts]
magproto.cc:750:35: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
if (current_time().toTime_t() > later) {
Should quit using Time_t. Fix the type for 'later'.
nmea.cc:678:8: warning: variable ‘scn’ set but not used
[-Wunused-but-set-variable]
int scn,cnt;
This was about the only one that indicated an actual bug. Fixed. (weakly)

...
For now,
adding || defined (__CYGWIN__) to that list probably works.

Probably.
Bingo! That DOES in fact work!
That should probably be solved "better", but for now, I've added that
just to remove the obstacle for any Cygwin users in the audience. A
better fix would test for the foo64() functions in configure and set
the existing IOAPI_NO_64 manifest and remove my hack.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Gpsbabel-code mailing list http://www.gpsbabel.org
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code

[Robert Lipe]

I DO recall that horror and recognize the blood you spilled on that.

I'm nervous about zlib/minizip, but the alternatives remain worse. Garmin
is really pushing their new ggz format (which I've only recently started
working on...) and it's pretty much a zip of gpx files with a bolted on
index of offsets into those gpx files in a container looking like a .geo or
similar overview. It's totally gross and seems to exist only to paper over
Garmin's broken/slow gpx reader. There are reasons I've not submitted that
format "for real". OK, one of those reasons is that I have yet to make it
work for > 1 waypoint...

Cygwin isn't really a strategic target for us. The changes discussed so far
will result in a link error if we're wrong. I kinda DO expect trouble in
this area eventually.

Post by tsteven4
I am still nervous about zlib after our troubles in the recent past.
Does r5003 work with 32 bit cygwin and 64 bit cygwin? I don't remember the
trouble that led to r4824, but I don't relish going down that path again.
Opening note: If you're a dabbler in programming, there's about a dozen
independent projects laid out below. Each is small - most are a dozens of
lines of code or less and we could use a hand with more contributors in the
code.
adding gpsbabel-code for the bitslingers.
gpsbabel-misc -> bcc for closure on that list.

checking for random stuff to make you feel better... failed
I'm not at all sure what to make of it.

It means I had a theory that nobody ever read that giant wall of text.
You're like the third person in ~15 years and millions of downloads to
notice it. :-)
The other warnings originated from the compiler. Apart from "sign-com-

pare" type warnings I got plenty of "unused-but-set-variable" (and it's
a bit enervating to read about set but unused variables like "lat" and
"lon" in a GPS program), a few "char-subscripts", two "array-bounds" and

I checked in r5002 that cleans up a lot of these. All were benign.
It's pretty common in code that reads disk files to have to read some bytes
and have some idea what they are but not need them. It's handy to give
them a name. The lat/lon cases were all of the form.
lat = read_N_bytes();
lon = read_N_bytes();
something_important = read_N_bytes()
#if DEBUG
print something_important about lat/lon
#endif
...we have to read those bytes, but if we're not debugging, we don't DO
anything with them. "fixed" by decorating (void).
one "comment" type warning (not sure whether or not these only show up

under Cygwin, so I'll go into the trouble of listing them all here).

It looks like GCC 4.8 has added a bunch of hyperactive warnings to
-Wall. We should probably turn these off unless someone else wants to do
the work of cleaning these up. I've ripped through the mechanical ones and
fixed them, but I'll scribble notes on the remaining ones that actually
need some thought in the hope that it helps budding Bablers tackle small
projects. (I think I'm traveling 3 of the next 4 weeks...)

route.cc: In function ‘void track_recompute(const route_head*,
route.cc:664:84: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
if (thisw->GetCreationTime().isValid() &&
(thisw->GetCreationTime().toTime_t() < tdata->start)) {
^
route.cc:668:41: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
if (thisw->creation_time.toTime_t() > tdata->end) {

route.cc should quit using toTime_t. tdata needs to use appropriate data
types.

strptime.c:302:5: warning: array subscript has type ‘char’
[-Wchar-subscripts]
if (isspace(*fmt)) {
^
strptime.c:303:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:520:7: warning: array subscript has type ‘char’
[-Wchar-subscripts]
while (isspace(*rp)) {
^
strptime.c:289:21: warning: variable ‘era’ set but not used
[-Wunused-but-set-variable]
struct era_entry *era;
^
strptime.c:277:15: warning: variable ‘rp_backup’ set but not used
[-Wunused-but-set-variable]
const char *rp_backup;

Should look for an update version of strptime from upstream. Better yet,
find remaining uses of strptime and replace them with QDateTime methods.
Unfortunately, we may have to keep strptime for csv_util because we expose
them in the csv files and the Qt format strings aren't QUITE the same as
the strptime. (Frankly, if it was the only remaining use, I'd go fix our
own style files and remove strptime and just say that's the new scheme...)

jeeps/gpsapp.cc:1682:18: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (gps_time != 0xffffffff && gps_time != 0) {

Cast it or make the constant U ?
jeeps/gpscom.cc: In function ‘int32 GPS_Command_Send_Course(const char*,

GPS_SCourse**, GPS_SCourse_Lap**, GPS_STrack**, GPS_SCourse_Point**, int32,
jeeps/gpscom.cc:806:13: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (n_crs > limits.max_courses
^
jeeps/gpscom.cc:807:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_clp > limits.max_course_laps
^
jeeps/gpscom.cc:808:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_trk > limits.max_course_trk_pnt
^
jeeps/gpscom.cc:809:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
|| n_cpt > limits.max_course_pnt) {

This is Gerhard's course stuff; I'm not sure we ever even actually use it.
Maybe we should compile that course stuff away totally.
Meta Grouchiness about Jeeps: Can'd decide between CamelCase and
underbar_separators? Why not BOTH!
t has type ‘char’ [-Wchar-subscripts]

magproto.cc:750:35: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (current_time().toTime_t() > later) {

Should quit using Time_t. Fix the type for 'later'.

nmea.cc:678:8: warning: variable ‘scn’ set but not used
[-Wunused-but-set-variable]
int scn,cnt;

This was about the only one that indicated an actual bug. Fixed. (weakly)

...

For now,

adding || defined (__CYGWIN__) to that list probably works. Probably.

Bingo! That DOES in fact work!

That should probably be solved "better", but for now, I've added that just
to remove the obstacle for any Cygwin users in the audience. A better fix
would test for the foo64() functions in configure and set the existing IOAPI_NO_64
manifest and remove my hack.
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/
_______________________________________________