Re: [gpsd-dev] compile issue: header not necessarily included for atomic_thread_fence

[Gary E. Miller]

Yo Gergely!

On Sun, 29 Nov 2015 17:30:49 +0800
Gergely Imreh <address@hidden> wrote:

> > Intel CPU?  What version of glibc?
> Yes, Intel i7 M 620. glibc is at 2.22.

Thanks, pretty vanilla.

> Hm, not quite sure about this. As much as I tried this and checked in
> some soruces, extern "C" only works in C++ (thus within a #ifdef
> _cplusplus block) since it's not valid C, so the above code would not
> compile.

Yeah, I mismatched the ifdefs, we don't want to include stdataomic.h
if we are runnning covertiry, and we want to wrap stdatomic.h in an
extern C{} is we are on c++.

> Also looking at some other sources[1], stdatomic.h is not compatible
> with C++, where "#include <atomic>" should be used. Not sure if
> anything has changed since a middle off 2014 when the linked bug
> report was written.
> 
> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932

That is a good reference, this is the end result:

        " If you want to use atomics in C, use <stdatomic.h>, and if
        you want to use them in C++, use <atomic> and appropriate
        using-declarations or a using-directive.:


> Though now it sort of makes sense why to have a check in the first
> place. But I don't think the purpose of the fix is to include the
> header necessarily, but rather not to call a function that has no
> header included... Just a thought.

To untanlge that thought, the purpose is to call the atomic functions
only if we have atomic support and the atomic header file.

From you bug, it seems the simple solution iis just to include <atomic>
if we are _cplusplus otherwise <stdatomic.h> if we have it.

How about you try that?

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

pgp_nkkeHUZwQ.pgp
Description: OpenPGP digital signature