gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Mingw port


From: Ukygerkgubiekd Ukygerkgubiekd
Subject: Re: [gpsd-dev] Mingw port
Date: Thu, 9 Aug 2012 03:56:20 -0700 (PDT)

Hi Eric,

That initial mingw port was just 
for exploratory purposes. It's served that purpose; I know now what the 
major stumbling blocks are.

Here is another branch, containing solely cleanups, all of which I believe are 
suitable to merge:

https://github.com/ukyg9e5r6k7gubiekd6/gpsd/tree/cleanups

Please pull, or cherry-pick, or tell me how to remedy, as you see fit.

This compiles cleanly under Linux, all regression tests pass, it's 100% 
splint-clean and it's almost cppcheck-clean.
The two remaining errors from cppcheck look like a bug in it:

libgps_sock.c:334: error: sscanf 
width 8 in format string (no. 1) is larger than destination, use %-1s to 
prevent overflowing destination: tag[0]
libgps_sock.c:407: error: sscanf width 8 in format string (no. 1) is 
larger than destination, use %-1s to prevent overflowing destination: 
tag[0]


Splint seems to be using sizeof(tag[0])==1 (too small), rather than 
sizeof(tag)==MAXTAGLEN+1==9 (just big enough) as it should.

I've been unable to find any way to silence 
these cppcheck errors, while still keeping both splint and the compiler happy 
and getting executables that actually work.
I'm not going to start hacking on cppcheck just now, so I've reluctantly given 
up on this.

Regards,

Matt



----- Original Message -----
From: Eric S. Raymond <address@hidden>
To: Ukygerkgubiekd Ukygerkgubiekd <address@hidden>
Cc: "address@hidden" <address@hidden>
Sent: Tuesday, 31 July 2012 2:09 PM
Subject: Re: [gpsd-dev] Mingw port

Ukygerkgubiekd Ukygerkgubiekd <address@hidden>:
> However, Windows has a completely different set of APIs for serial comms, and 
> for timing/handshaking/waiting etc.
> 
> To get drivers, the daemon and the regression tests working under Windows 
> hence requires some abstraction layer over those differences.
> 
> My idea is that such a layer could also incorporate the existing differences 
> between shm, dbus, QT, sockets and fds.
> Your comments appreciated!

Sounds useful if done right, but quite ugly and obtrusive if done wrong.

I am, at least, open to refactoring changes that would narrow thw coupling to 
the base OS.  Most of the changes would be in gpsd.c and serial.c, correct?
-- 
        <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]