In the client API, take the data buffer out of the gpsdata_t structure.

tz has shown me that we had a point of brittleness where the size
of the client's data buffer was exposed in gps_data_t. Solution:
move it (and the data-waiting count) to the client's private-data
member.  Requires a new but trivial client-library entry point to get
the buffer pointer when a client needs it.

Had to be done before API Version 5 froze, or we'd have been stuck breaking
a shipped API again.

No implications for the daemon or other tools, as this buffer is never
used there.  (Except it gets rid of several K of never-used static
buffer space in the daemon, which is a good thing.)

All regression tests pass. Code splints clean.  cgps (the only place
the API fix matters in our code) live-tests correctly.

1 files changed, 1 insertions, 1 deletions

diff --git a/cgps.c b/cgps.c
index 5d9200d6..6fac00cb 100644
--- a/cgps.c
+++ b/cgps.c
@@ -693,7 +693,7 @@ static void update_gps_panel(struct gps_data_t *gpsdata)
 
     /* Be quiet if the user requests silence. */
     if (!silent_flag && raw_flag) {
-	(void)waddstr(messages, gpsdata->buffer);
+	(void)waddstr(messages, gps_data(gpsdata));
     }
 
     /* Reset the status_timer if the state has changed. */