Dangerous #define clause

[armallen]

Hi,

I am currently using RTKLIB in a C++ multithreaded program.

The following code in rtklib.h conflicts with any other code using std::mutex

#define lock(f)     pthread_mutex_lock(f)
#define unlock(f)   pthread_mutex_unlock(f)

Here is a sample code showing the problem:

#include "rtklib.h"
#include <mutex>
using namespace std;

int main() {

    std::mutex m;
    m.lock();
    m.unlock();

    // Some rtklib code...

    return (0);
}

Compiling with g++ 4.8.5 causes the following error:

In file included from ../src/mutexLock.cpp:2:0:
/usr/include/c++/4.8.2/mutex:708:44: error: macro "lock" passed 3 arguments, but takes just 1
     lock(_L1& __l1, _L2& __l2, _L3&... __l3)

[DavidKelleySCSC]

We had the same issue with a Qt based server project that used RTKLIB on both Win and Linux. Solved it by simply redefining the macro to avoid the conflicts with RTKLIB vs Linux. Here is all it took.

// Comment out below line to use RTKLIB machong and DISABLE
// the use of the QMutex lock / unlock in Caster Table Management code
// CAUTION:  using USE_RTK_NATIVE results in race condition in caster class, but
// not having it (using the 2nd entry for a renamed patch) results in Linux compile errors
//

#ifdef USE_RTK_NATIVE
    #define lock(f)     EnterCriticalSection(f)
    #define unlock(f)   LeaveCriticalSection(f)
#else
    #define RTKlock(f)     EnterCriticalSection(f)
    #define RTKunlock(f)   LeaveCriticalSection(f)
#endif
// DCK End changes

#define FILEPATHSEP '\\'
#else
    #define thread_t    pthread_t
    #define lock_t      pthread_mutex_t
    #define initlock(f) pthread_mutex_init(f,NULL)
    #define RTKlock(f)  pthread_mutex_lock(f)
    #define RTKunlock(f)pthread_mutex_unlock(f)
    #define FILEPATHSEP '/'
#endif

[armallen]

This obviously works, but, in my opinion, this is only a workaround.
RTKLIB still should not have such side effects on users' code, especially using such widely used keywords.

I don't know the exactu use for these macros, maybe they could be isolated in a separated header file?

[reid-p]

On 5/02/2019 6:05 pm, Arnaud Mallen wrote: This obviously works, but, in my opinion, this is only a workaround. RTKLIB still should not have such side effects on users' code, especially using such widely used keywords. I don't know the exactu use for these macros, maybe they could be isolated in a separated header file?

Yes it'd be nice if all defines in the public headers where prefix with RTK_ or similar to help avoid collisions. There's a bunch of things that'd be nice to cleanup in the code base but there doesn't seem to be much activity in accepting patches.

…

-- Regards Phil Reid

[DavidKelleySCSC]

Was just looking at this today as I ported a few improvements over to our code base. If you patch this, be sure and do the same to similar lock code in both stream.c and rtkrcv.c as well.

[thesamprice]

https://github.com/tomojitakasu/RTKLIB/pull/498/files Is this related to this pull request? Sent from my phone.

On Oct 24, 2019, at 10:16 AM, DC Kelley ***@***.***> wrote:

 Was just looking at this today as I ported a few improvements over to our code base. If you patch this, be sure and do the same to similar lock code in both stream.c and rtkrcv.c as well. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Henkecool]

Issue #527 mentions the same thing as you are discussing. The issues (and more) are fixed in pull request #579.