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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Robert Lipe-2
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.


The first message that caught my eye was from "configure":

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*, computed_trkdata**)’:
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: In function ‘strptime_internal’:
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*, int)’:
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, int32, int32, 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: In function ‘void mag_serial_init_common(const char*)’:
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: In function ‘void gpgsa_parse(char*)’:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

tsteven4-2
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.

On 7/8/2015 12:20 PM, Robert Lipe wrote:
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.


The first message that caught my eye was from "configure":

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*, computed_trkdata**)’:
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: In function ‘strptime_internal’:
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*, int)’:
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, int32, int32, 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: In function ‘void mag_serial_init_common(const char*)’:
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: In function ‘void gpgsa_parse(char*)’:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Robert Lipe-2
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.

On Wed, Jul 8, 2015 at 6:24 PM, tsteven4 <[hidden email]> wrote:
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.


On 7/8/2015 12:20 PM, Robert Lipe wrote:
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.


The first message that caught my eye was from "configure":

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*, computed_trkdata**)’:
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: In function ‘strptime_internal’:
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*, int)’:
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, int32, int32, 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: In function ‘void mag_serial_init_common(const char*)’:
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: In function ‘void gpgsa_parse(char*)’:
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Loading...