nonstandard c++ mutable ref in cac

[Jeff Hill]

the channel access client library source code uses some instances of mutable references and this is not allowed in standard c++, and is causing some issues with the new Clang compiler on Max OSX.

On Mar 11, 2011, at 9:27 PM, Jeff Hill wrote:

> Hi Tom,
>
> I wasn’t aware of that, and it probably needs to
> be fixed. The reference counting mutex class on the
> cvs trunk might be a clean workaround. Also, presumably
> the quick fix is to just use instead, a mutable
> _pointer_.
>
>

>> -----Original Message-----
>> From: Andrew Johnson
>> Sent: Friday, March 11, 2011 12:39 PM
>> To: Jeff Hill; EPICS core-talk
>> Cc: Pelaia II, Tom
>> Subject: Fwd: C++ compatibility
>>
>> Hi Jeff,
>>
>> An issue for you from the CA client library. Tom's right about the rule
>> (this
>> is not a recent change either, it's present in my 1998 first edition of
>> the
>> spec), but I have no idea why the restriction exists. I'm guessing that
>> Apple's clang C++ compiler has started to check this.
>>
>> Thanks Tom.
>>
>> - Andrew
>>
>> ---------- Forwarded Message ----------
>>
>> Subject: C++ compatibility
>> Date: Friday 11 March 2011
>> From: "Pelaia II, Tom"
>> To: Andrew Johnson
>>
>> Hi Andrew,
>>
>> I believe there is an error in some EPICS base source files in which
>> reference
>> members are declared mutable:
>>
>> In file included from ../cac.cpp:39:
>> ../cac.h:269:5: error: 'mutable' cannot be applied to references
>> mutable epicsMutex & mutex;
>> ^
>> ../cac.h:270:5: error: 'mutable' cannot be applied to references
>> mutable epicsMutex & cbMutex;
>> ^
>> In file included from ../cac.cpp:47:
>> ../udpiiu.h:152:5: error: 'mutable' cannot be applied to references
>> mutable epicsMutex & cbMutex;
>> ^
>> ../udpiiu.h:153:5: error: 'mutable' cannot be applied to references
>> mutable epicsMutex & cacMutex;
>> ^
>>
>>
>> The C++ specification (section 7.1.1 item 10) explicitly forbids mutable
>> reference members:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
>>
>> Best regards,
>> Tom
>> ___________________________________________________
>> Tom Pelaia | homepage: http://www.ornl.gov/~t6p
>>

[Jeff Hill (johill-lanl)]

Another user has noticed this issue

Hello.
I've tried building EPICS base on the latest Fedora 15.

First problem I encountered was

In file included from ../../../src/libCom/cxxTemplates/epicsOnce.cpp:29:0:
../../../src/libCom/cxxTemplates/epicsSingleton.h:37:5: error: ‘size_t’
does not name a type

My fix for that was to include
 #include "stddef.h"
in the file
       EPICS_BASE/src/libCom/cxxTemplates/epicsSingleton.h

Next problem while compiling epics base is

In file included from ../cac.cpp:39:0:
../cac.h:269:26: error: reference ‘mutex’ cannot be declared ‘mutable’
[-fpermissive]
../cac.h:270:26: error: reference ‘cbMutex’ cannot be declared ‘mutable’
[-fpermissive]
In file included from ../cac.cpp:47:0:
../udpiiu.h:152:26: error: reference ‘cbMutex’ cannot be declared
‘mutable’ [-fpermissive]
../udpiiu.h:153:26: error: reference ‘cacMutex’ cannot be declared
‘mutable’ [-fpermissive]
make[3]: *** [cac.o] Error 1

I think that this thread is referring to the same problem.
http://www.aps.anl.gov/epics/core-talk/2011/msg00029.php

Any suggestion how to resolve that 'mutable' compilation issue?
Thanks.

Miroslav

--
Miroslav Mihaylov
<email address hidden>

[Jeff Hill (johill-lanl)]

The solution will be to change the mutex reference into a pointer (which will not need to be mutable). A bug entry has been opened against this issue, but it looks like a patch hasn't been installed at this time. This is of course an issue with the very latest gcc.

https://bugs.launchpad.net/epics-base/+bug/736273

In the future it will be preferable to use the improved epicsMutex class which allows reference counting of the mutex instance.

[Jeff Hill (johill-lanl)]

> In file included from ../../../src/libCom/cxxTemplates/epicsOnce.cpp:29:0:
>../../../src/libCom/cxxTemplates/epicsSingleton.h:37:5: error: ‘size_t’
> does not name a type

The issue here may be that size_t is only in the std namespace, and so we
need to add "using std :: size_t" or change the declarations to use "std ::
size_t"

> My fix for that was to include
> #include "stddef.h"

In recent codes I prefer including <cstddef> and importing from namespace
std as needed. However, it may be that that header already includes a
standard library header that defines "std :: size_t", and so including
<cstddef> might be superfluous.

[Andrew Johnson (anj)]

Jeff,

There are no patches or branches attached to this bug report, so I have nothing to merge yet that fixes it — when you wrote "it looks like a patch hasn't been installed at this time" had you already developed a fix?

- Andrew

[mdavidsaver (mdavidsaver)]

When this bug was first reported I did a quick check (sorry for not following up). From what I can tell these references are never actually "mutated" so I think it is safe to just remove the qualifiers.

Of course this assumes that what is being referenced isn't being treated as a pointer in other contexts. I don't think this is happening, but I am not certain.

[Ralph Lange (ralph-lange)]

The size_t issue is not fixed with the first patch - adding another one.

[Ralph Lange (ralph-lange)]

Applied patch to 3.14 branch.