Re: [Gpsbabel-code] Proposed change to mapsource.c

[Robert L. <rob...@us...>]

> structures.  As mapsource.c grows, the sync task becomes worse and worse
> and as I propose to start work on MapSource V6 (GDB) support, the task
> is about to become a whole lot worse.

Yeah, there's probably a lesson that mapsource.c is the largest module
in the tree.

> So, my issue is that I'd like to merge mapsource.c and my dump utility
> into one, so that program logic / flow is in one place only.  To my

How much life do we really think mapsource.c has left in it?  Since
Garmin has ditched the format and the upgrades to Mapsource v6 are
free, is it worth it at this point to get too radical with mapsource.c
or should we focus our efforts on making gdb.c that avoids these
maintenance problems?

> limited-experience mind, the "obvious" way to do this is to use a raft
> of conditional compilation statements.  This way, the source grows by,
> say 25%, but the production binary stays as is. But, is this somehow

You can make it a little bit better with something like 

#if defined WANT_MPS_DEBUG
# define MPSDEBUG(m) printf m
#else
# define MPSDEBUG(m)
#endif

Use it with varargs, but include double parens:
MPSDEBUG(("message %d", i));

(C99 has a better way do do this, but that's the safe way in C89.)

That at least means you don't have the #if tests inline.

> PS If you were wondering, I shall be using the excellent work of Chris
> Spray and Ian Cowley as the source for the format of GDB. Okay, you
> weren't wondering.

They seem to have done a good job.

As I read thier document, I found myself wondering if it might be cleaner
to build data descriptors that mirrored the data structures.   That might 
make future revs of GDB easier to cope with than we've had with mapsource.
I haven't really thought it all through, but ...

mps_rec mps_track_rec {
	MPS_LONG, rd_record_size, wr_record_size, NULL,
	MPS_BYTE, rdbyte, wrbyte, 'T',
	MPS_ZSTR, rdzstr, wrzstr, offsetof(route_head, rte_name),
	[ ... ] 
	MPS_POSN, rdposn, wrposn, offsetof(waypt, latitude),
	MPS_POSN, rdposn, wrposn, offsetof(waypt, longitude),
	MPS_POSN, rdposn, wrposn, offsetof(waypt, altitude),
	MPS_END,
};

And keep defining upwards until you have a top-level 'struct
mapsource_file' that has everything in the file in the order they'd
appear.

Then, in one place, you have a function called 'rdposn' knew how one of
these things was described and where to put it.  Its twin, wrposn, knew
how to create one of these things, handle that it's optional, cope with
endiannness, and return the number of bytes moved.  So to write a track
record, you just loop over this thing.  In GDB version 1.01 when the
track record gets alphabetized, we just include a new toplevel struct that
includes mps_track_rec_1_0_1 that reflects the reordering.

I don't know if it'd work, but it was just something that I thought
about while reading that or the Garmin protocol spec.

RJL