diff options
author | Chris Kuethe <chris.kuethe@gmail.com> | 2007-03-21 21:37:22 +0000 |
---|---|---|
committer | Chris Kuethe <chris.kuethe@gmail.com> | 2007-03-21 21:37:22 +0000 |
commit | ec2599f2ee5a34cc007fc67208f74a242a1c95e3 (patch) | |
tree | f32bfda3acde1133adff4640169f1683f08d4546 /TODO | |
parent | 605932ed8ac63ed40d7e0bba2c5b490daf56f31c (diff) | |
download | gpsd-ec2599f2ee5a34cc007fc67208f74a242a1c95e3.tar.gz |
This was dealt with in my last change of 06 Jan 2007.
I don't think that it's a bug on our part to have a certain
expectation about number formats - especially when we make that
explicit by forcing the use of the C locale on the wire.
It's not a bug in libc either - users have every right to ask the
computer to display data in a format they're comfortable with. In this
case, since the gpsd protocol is a wire protocol that happens to be
fairly human-readable too, the computer's preference is dominant. For
display engines (like cgps/xgps) the user preference can dominate.
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 8 |
1 files changed, 0 insertions, 8 deletions
@@ -29,14 +29,6 @@ SiRF support; it works OK in NMEA mode. The Royaltek died in an accident, so we're stuck until someone else can test this. We think it is very likely that changes since 2.28 have fixed this bug. -*** gps_unpack() can be confused by a changed locale - -gps_poll() uses gps_unpack(), which uses sscanf(). The behavior -of sscanf() can be changed so this instance doesn't work any more -by changing the system locale. The workaround is to do -setlocale(LC_NUMERIC, "C"); the fix would be to use a parsing -method that is independent of locale. - ** To do: *** Fix endian/word-size sensitive code |