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/gps_json.h b/gps_json.h
index e5a82594..bf5150d2 100644
--- a/gps_json.h
+++ b/gps_json.h
@@ -8,7 +8,7 @@
 #include "json.h"
 
 #define GPS_JSON_COMMAND_MAX	80
-#define GPS_JSON_RESPONSE_MAX	1536
+#define GPS_JSON_RESPONSE_MAX	4096
 
 #ifdef __cplusplus
 extern "C" {