More small pre-release cleanups.

TODO

@@ -11,12 +11,12 @@ libgpsd_core.c and the TSIP driver that we haven't figured out.
 
 This may be a symptom of more general problems in data management
 on devices that ship several sentences of fix and related data
-per cycle.  It does not affect devices speaking SiRF or Zodac or 
+per cycle.  It does not affect devices speaking SiRF or Zodiac or 
 Garmin-binary protocol.
 
 *** PPS code is flaky, possibly due to a pthreads bug
 
-Some code attempting to terminate the PPS-monutoring thread when there
+Some code attempting to terminate the PPS-monitoring thread when there
 is no DCD (e.g., on a USB device) seems to have tickled some kind of
 bug in pthreads -- termination seems to close the GPS device or
 otherwise do something nasty to the serial I/O layer.  
@@ -84,9 +84,6 @@ memory resource crises do something nasty to the buffering in the
 Linux serial layer.  The bug seems not to occur during ext3 backups,
 only Reiserfs ones.
 
-This probably means we need to get rid of the FIONREAD ioctl(), which
-has always been kind of dodgy anyway.
-
 ** To do:
 
 *** Track error computation

dgpsip-servers

@@ -0,0 +1,10 @@
+# Publicly available DGPS correction servers
+# Three fields are: Latitude, longitude, server name[:port]
+# Degree fractional parts are decimal, not mmss.  They can be approximate,
+# as they are only used to find the closest server.
+# Some of the data in this file is from the EUREF project page at
+# http://www.epncb.oma.be/_organisation/projects/euref_IP/
+#
+37.19	-122.39	dgps.wsrcc.com  	# Pt. Blunt, CA USA
+39.14	8.97	glonass.ca.astro.it	# Cagliari, Italy
+50.01	19.92  	gps1.geod.agh.edu.pl	# Krakow, Poland

dgpsip.c

@@ -98,12 +98,12 @@ void dgpsip_autoconnect(struct gps_context_t *context,
 			const char *serverlist)
 /* tell the library to talk to the nearest DGPSIP server */
 {
-    char buf[BUFSIZ];
     struct dgps_server_t {
 	double lat, lon;
-	char server[255];
+	char server[257];
 	double dist;
     } keep, hold;
+    char buf[BUFSIZ];
     FILE *sfp = fopen(serverlist, "r");
 
     if (sfp == NULL) {

gpsd.h

@@ -25,20 +25,22 @@
 /* only used if the GPS doesn't report estimated position error itself */
 #define UERE_NO_DGPS	8	/* meters */
 #define UERE_WITH_DGPS	2	/* meters */
-#define UERE(session)	((session->context->dsock==-1) ? UERE_NO_DGPS : UERE_WITH_DGPS)
+#define UERE(session)	((session->context->dsock<0) ? UERE_NO_DGPS : UERE_WITH_DGPS)
 
 #define NTPSHMSEGS	4		/* number of NTP SHM segments */
 
 struct gps_context_t {
-    int valid;
+    int valid;				/* member validity flags */
 #define LEAP_SECOND_VALID	0x01	/* we have or don't need correction */
+    /* DGPSIP status */
     bool sentdgps;			/* have we sent a DGPSIP R report? */
     int fixcnt;				/* count of good fixes seen */
     int dsock;				/* socket to DGPS server */
     ssize_t rtcmbytes;			/* byte count of last RTCM104 report */
     char rtcmbuf[40];			/* last RTCM104 report */
     double rtcmtime;			/* timestamp of last RTCM104 report */ 
-    int leap_seconds;
+    /* timekeeping */
+    int leap_seconds;			/* Unix seconds to UTC */
     int century;			/* for NMEA-only devices without ZDA */
 #ifdef NTPSHM_ENABLE
     /*@reldef@*/struct shmTime *shmTime[NTPSHMSEGS];

gpsd.spec.in

@@ -131,7 +131,7 @@ cp gps.py gpsfake.py "$RPM_BUILD_ROOT"%{_libdir}/python${PYVERSION}/site-package
   buffering problems with the Python side of the hotplug interface.
   gpsfake can now run sessions under a monitor like Valgrind.  Most
   of the gpsfake logic now lives in a module that can be used to write
-  other test loads.  Its progress baton is now optional.  Fixed
+  other test loads; its progress baton is now optional.  Fixed
   some minor bugs found by valgrind audit, including (1) a slow
   memory leak, (2) a possible but unconfirmed file-descriptor leak, 
   and (3) a subtle error in the channel-assignment logic that only