Re: [gpsd-dev] The attempt to use VTIME has been removed

[Gary E. Miller]

Yo Eric!

On Sat, 31 Jan 2015 17:58:17 -0500
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > Along the way I noticed the ppsthread uses strerror() a lot, but
> > that is not thread safe.  No reports of that causing an issue, but
> > should eentually be fixed.  strerror_r() is not a portable
> > replacement.
> > 
> > Any ideas on a thread safe and portable replacement to strerror()?
> 
> According to strerror(3), glibc provides a POSIX strerror_r() if you
> set the right feature macros.  I'd say do that.

I considered that, but, Windows does not have strerror_r(), and are all
other gpsd hosts POSIX?

We would need to match this:

   (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE

Which conflicts with current SContruct:

    # We need to define -D_GNU_SOURCE
    env.Append(CFLAGS='-D_GNU_SOURCE')

Can gpsd assume the _GNU_SOURCE version of strerror_r() is always
available on all known gpsd hosts?  Sadly POSIX strerror_r() and GNU
strerror() are incompatible!

C11 specifies the optional to implement strerror_s() which is also in
Windows, but not much C11 compatibility around yet and it is not in GNU yet.

Eventually we need a strerror_gpsd() that picks the best of any available
strerror_?().  At least for ppsthread.

In any case, probably nothing we want to try when you want to get a
release out.  Low risk to leave it alone until after release.  If
something urgent needed to be done I'd just remove strerror() from
ppsthread.c and just output the errno.  No sign of urgency.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588