epics-base/pvdatacpp

pvDataCPP is an EPICS V4 C++ module

pvdatacpp's Issues

Invalid conversion to JSON for strings that contain double quotes

The printJSON() method results in invalid JSON if strings contain double quote characters (see epics-base/pvaPy#74).

DEBUG_PTR does not work with base 7.0.7

The flag DEBUG_PTR was added in order to better track shared pointer usage. However, it is not compatible with a few changes to EPICS base since then:

• epics-base/pvAccessCPP@161eac3 - adds ->expired() to weak_ptr
• epics-base/pvAccessCPP@32c51c8 - adds write to an ostream that is not resolve correctly (as near as I can tell, due to another possible match in reftrack.h).

Proposed fix will be added in a merge request.

`isctype.c(68) : Assertion failed: c >= -1 && c <= 255`

I noticed that one of the appveyor runs triggering an assertion failure in printer.cpp. The MS documentation is clear enough:

The behavior of isprint and _isprint_l is undefined if c isn't EOF or in the range 0 through 0xFF, inclusive.
When a debug CRT l>ibrary is used and c isn't one of these values, the functions raise an assertion.

https://ci.appveyor.com/project/epics-base-7/epics-base/builds/45492554/job/5tauw07hyhd8qn22

f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c(68) : Assertion failed: c >= -1 && c <= 255
Dumping a stack trace of thread 'win440':
[  74F35CF5]: c:\projects\epics-base\modules\libcom\src\osi\os\win32\osdbacktrace.cpp[line 23](epicsBackTrace+0x25)
[  74F35A25]: c:\projects\epics-base\modules\libcom\src\osi\epicsstacktrace.c[line 80](epicsStackTrace+0x85)
[  74F26EF4]: c:\projects\epics-base\modules\libcom\src\misc\epicsunittest.c[line 94](testReportHook+0x34)
[  7495E942](_VCrtDbgReportW+0x5c2)
[  74955CF4](_CrtDbgReportW+0x74)
[  74955CAD](_CrtDbgReportW+0x2d)
[  748F586C](_chvalidator+0x2c)
[  748F3C6A](isprint+0x1a)
[  74AB01B5]: c:\projects\epics-base\modules\pvdata\src\factory\printer.cpp[line 500](epics::pvData::operator<<+0xf5)
[  74AB0541]: c:\projects\epics-base\modules\pvdata\src\factory\printer.cpp[line 544](epics::pvData::operator<<+0x121)
[  74A5D502]: c:\projects\epics-base\modules\pvdata\src\factory\pvdatacreatefactory.cpp[line 147](epics::pvData::PVString::dumpValue+0x32)
[  74A50B67]: c:\projects\epics-base\modules\pvdata\src\factory\pvfield.cpp[line 94](epics::pvData::operator<<+0x17)
[  74A59CE2]: c:\projects\epics-base\modules\pvdata\src\factory\pvunion.cpp[line 191](epics::pvData::PVUnion::dumpValue+0x272)
[  74A50B67]: c:\projects\epics-base\modules\pvdata\src\factory\pvfield.cpp[line 94](epics::pvData::operator<<+0x17)
[  74A52F9E]: c:\projects\epics-base\modules\pvdata\src\factory\pvstructure.cpp[line 321](epics::pvData::PVStructure::dumpValue+0x2be)
[  74A50B67]: c:\projects\epics-base\modules\pvdata\src\factory\pvfield.cpp[line 94](epics::pvData::operator<<+0x17)
[  74A60076]: c:\projects\epics-base\modules\pvdata\src\factory\pvdatacreatefactory.cpp[line 778](std::operator<<+0x16)
[  00D64389]: c:\program files (x86)\microsoft visual studio 11.0\vc\include\memory[line 816](std::operator<<<char,std::char_traits<char>,epics::pvData::PVStructure>+0x19)
[  00D624D5]: c:\projects\epics-base\modules\pvdata\testapp\misc\testjson.cpp[line 175](`anonymous namespace'::testInto+0x525)
[  00D63285]: c:\projects\epics-base\modules\pvdata\testapp\misc\testjson.cpp[line 285](main+0x75)
[  00D72249]: f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c[line 536](__tmainCRTStartup+0x199)
[  00D7238D]: f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c[line 377](mainCRTStartup+0xd)
[  755A6A14](BaseThreadInitThunk+0x24)
[  77A8AD8F](RtlInitializeExceptionChain+0x8f)
[  77A8AD5A](RtlInitializeExceptionChain+0x5a)
f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c(56) : Assertion failed: c >= -1 && c <= 255
Dumping a stack trace of thread 'win440':

This is pointing to

pvDataCPP/src/factory/printer.cpp

Line 485 in 45671fa

const char C = Q.orig[pos];

...

pvDataCPP/src/factory/printer.cpp

Line 500 in 45671fa

if(!isprint(C)) {

get operation on softIOC pv don't return timeStamp field

Hello EPICS group
I'm working with last epics release and I have notice that making a get operation for an IOC using a CA provider for crete a pvac::ClientChannel I don't receive the timestamp field:

I noticed that also the official caget has the problem:

developer@e058f4bc2090:/workspace$ pvget variable:sum
variable:sum 2023-05-05 16:34:54.607 3
developer@e058f4bc2090:/workspace$ caget variable:sum
variable:sum 3

so is a client library problem or a server or something else?

Problem building pvDataCPP with c++11 on macos

I noticed a problem build pvData on macos when building with -std=c++11. It seems to be an issue with PVValueArray templates. It builds fine for me with clang and c++11 under linux.

Output from the build failure of testApp/misc/testSerialization.cpp is below. It compiles but the linking step fails:

c++           -DPVD_INTERNAL    -DUNIX  -Ddarwin     -O3 -g   -Wall    -std=c++11 -stdlib=libc++   -arch x86_64    -fno-common  -I. -I../O.Common -I. -I. -I.. -I../../testApp/misc -I../../testApp/pv -I../../testApp/property -I../../testApp/copy -I/Users/ddamiani/Workarea/epics-base/include/compiler/clang -I/Users/ddamiani/Workarea/epics-base/include/os/Darwin -I/Users/ddamiani/Workarea/epics-base/include -I/Users/ddamiani/Workarea/epics-base/include/compiler/clang -I/Users/ddamiani/Workarea/epics-base/include/os/Darwin -I/Users/ddamiani/Workarea/epics-base/include        -c ../../testApp/misc/testSerialization.cpp
c++ -o testSerialization  -L/Users/ddamiani/Workarea/epics-base/lib/darwin-x86        -arch x86_64            testSerialization.o    -lpvData -lCom   
Undefined symbols for architecture x86_64:
  "epics::pvData::PVValueArray<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::replace(epics::pvData::shared_vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<signed char>::replace(epics::pvData::shared_vector<signed char const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<char>::replace(epics::pvData::shared_vector<char const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<double>::replace(epics::pvData::shared_vector<double const, void> const&)", referenced from:
      _main in testSerialization.o
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<float>::replace(epics::pvData::shared_vector<float const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<unsigned char>::replace(epics::pvData::shared_vector<unsigned char const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<int>::replace(epics::pvData::shared_vector<int const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<unsigned int>::replace(epics::pvData::shared_vector<unsigned int const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<short>::replace(epics::pvData::shared_vector<short const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<unsigned short>::replace(epics::pvData::shared_vector<unsigned short const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<long long>::replace(epics::pvData::shared_vector<long long const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
  "epics::pvData::PVValueArray<unsigned long long>::replace(epics::pvData::shared_vector<unsigned long long const, void> const&)", referenced from:
      (anonymous namespace)::testArray() in testSerialization.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

MD: edit formatting

Unaligned access causing SIGBUS on Raspbian

Hardware: Respberry Pi 4B
OS: Raspbian GNU/Linux 11 (bullseye)
EPICS version：7.0.5、7.0.6.1、7.0.7

I built an IOC application with a simple db file:

#scale.db
record(calc,"Scale$(N)"){
field(INPA,"Scale$(N).VAL")
field(CALC,"A+1")
field(SCAN,".1 second")
}

I add pvAccess Server in the App/src/Makefile

#Link QSRV (pvAccess Server) if available
ifdef EPICS_QSRV_MAJOR_VERSION
siocScle_LIBS += qsrv
siocScle_LIBS += $(EPICS_BASE_PVA_CORE_LIBS)
siocScle_DBD += PVAServerRegister.dbd
siocScle_DBD += qsrv.dbd
endif

After make I run the ioc app and I can caget the channel for example Scale1. But when I use pvget the terminal running the ioc above exit the last message is epics> Bus error

Problem building pvDataCPP for win32-x86-mingw

I recently introduced Mark Rivers to the wonders of the MinGW compiler tool-set, which permits cross-building of Windows binaries using gcc on a Linux host (it also has a native copy of gcc that runs on Windows so it can be used either way). He has now started using this target, and reported the following build issue to core-talk this morning:

I get the following error building pvData on win32-x86-mingw.

Cross-compiler running on Linux.
Base 3.15.4
Version of pvData checked out by Andrew's pvPackage:
git clone --recursive [email protected]:anjohnson/pvPackageCPP.git

make[2]: Entering directory `/usr/local/epics/pvPackageCPP-3.15/pvData/src/O.win32-x86-mingw'
/usr/bin/i686-pc-mingw32-g++              -D_MINGW     -O3   -Wall       -m32   -DEPICS_BUILD_DLL -DEPICS_CALL_DLL   -I. -I../O.Common -I. -I. -I.. -I../../src/misc -I../../src/pv -I../../src/factory -I../../src/property -I../../src/copy -I../../src/pvMisc -I../../src/monitor -I../../include/compiler/gcc -I../../include/os/WIN32 -I../../include    -I/corvette/usr/local/epics/base-3.15.4/include/compiler/gcc -I/corvette/usr/local/epics/base-3.15.4/include/os/WIN32 -I/corvette/usr/local/epics/base-3.15.4/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvDatabase/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvaSrv/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvaClient/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvAccess/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/normativeTypes/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvData/include   -I/corvette/usr/local/epics/pvPackageCPP-3.15/pvCommon/include        -o pvCopy.obj -c ../../src/copy/pvCopy.cpp
../pv/pvData.h: In member function 'epics::pvData::StructureConstPtr epics::pvData::PVCopy::createStructure(const epics::pvData::PVStructurePtr&, const epics::pvData::PVStructurePtr&)':
../pv/pvData.h:705:29: sorry, unimplemented: inlining failed in call to 'epics::pvData::PVFieldPtr epics::pvData::PVStructure::getSubField(const std::string&) const': function not inlinable
../../src/copy/pvCopy.cpp:401:67: sorry, unimplemented: called from here
make[2]: *** [pvCopy.obj] Error 1
make[2]: Leaving directory `/usr/local/epics/pvPackageCPP-3.15/pvData/src/O.win32-x86-mingw'
make[1]: *** [install.win32-x86-mingw] Error 2
make[1]: Leaving directory `/usr/local/epics/pvPackageCPP-3.15/pvData/src'
make: *** [src.install] Error 2

Need versioning for serialization

I see that #24 highlights the lack of any concept of version in the present serialization APIs. At some point (imo #24 almost qualifies) it will be desirable to control the serialization format depending on peer protocol version to avoid backwards incompatible changes.

@msekoranja I'm not sure where this should go. Perhaps in the (de)serialization control interface?

FieldCreate::Helper - pure virtual function call

I've had two reports of a crash in the compare() call below in two different environments (gcc/Linux and msvc/win32).

pvDataCPP/src/factory/FieldCreateFactory.cpp

Lines 60 to 63 in 17fa7a7

	for(; itp.first!=itp.second; ++itp.first) {
	Field* cent(itp.first->second);
	FLD* centx(dynamic_cast<FLD*>(cent));
	if(centx && compare(*centx, *ent)) {

The WIN32 case specifically gives an error "pure virtual function call" which suggests to me that this isn't simply *NULL.

BE array serialization broken

The fix for #54 introduced a regression to ByteBuffer effecting serialization to big endian. The bug appears when an array is serialized by a BE peer, or from a BE peer. The effect is an out of bounds array access.

WIN32: debug assertion "failures"

Seen during an appveyor run (Environment: CMP=vs2013; Configuration: dynamic-debug; Platform: x64). The test didn't register any failures (all ok).

https://ci.appveyor.com/project/mdavidsaver/epics-base/builds/33248176/job/i165b2y5005ufg8i#L12543

perl -CSD testPVScalarArray.t -tap > testPVScalarArray.tap
Dumping a stack trace of thread 'win58c':
[  00007FFFCDB2D0D5]: c:\projects\epics-base\modules\libcom\src\osi\os\win32\osdbacktrace.cpp[line 22](epicsBackTrace+0x45)
[  00007FFFCDB2CD76]: c:\projects\epics-base\modules\libcom\src\osi\epicsstacktrace.c[line 79](epicsStackTrace+0x66)
[  00007FFFCDB1C07B]: c:\projects\epics-base\modules\libcom\src\misc\epicsunittest.c[line 80](testReportHook+0x4b)
[  00007FFFBD7C6722](_VCrtDbgReportW+0x6f2)
[  00007FFFBD7BB3B0](_CrtDbgReportW+0xd0)
[  00007FFFBD7BB340](_CrtDbgReportW+0x60)
[  00007FFFCACB65D1](?_Debug_message@std@@YAXPEB_W0I@Z+0x41)
[  00007FFFCDC21647]: c:\program files (x86)\microsoft visual studio 12.0\vc\include\xutility[line 548](std::_Debug_pointer<signed char>+0x47)
[  00007FFFCDC6E5AB]: c:\program files (x86)\microsoft visual studio 12.0\vc\include\xutility[line 2798](std::equal<signed char const * __ptr64,signed char const * __ptr64>+0x5b)
[  00007FFFCDC6D6C9]: c:\projects\epics-base\modules\pvdata\src\factory\compare.cpp[line 159](epics::pvData::`anonymous namespace'::compareArray<signed char>+0xb9)
[  00007FFFCDC6B70B]: c:\projects\epics-base\modules\pvdata\src\factory\compare.cpp[line 204](epics::pvData::`anonymous namespace'::compareField+0x1cb)
[  00007FFFCDC6B152]: c:\projects\epics-base\modules\pvdata\src\factory\compare.cpp[line 339](epics::pvData::operator==+0xc2)
[  00007FF696291CF8]: c:\projects\epics-base\modules\pvdata\testapp\pv\testpvscalararray.cpp[line 93](`anonymous namespace'::testBasic<epics::pvData::PVValueArray<signed char> >+0x118)
[  00007FF696291BA6]: c:\projects\epics-base\modules\pvdata\testapp\pv\testpvscalararray.cpp[line 206](main+0x36)
[  00007FF6962A7F2D]: f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c[line 626](__tmainCRTStartup+0x19d)
[  00007FF6962A805E]: f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c[line 466](mainCRTStartup+0xe)
[  00007FFFD6D313D2](BaseThreadInitThunk+0x22)
[  00007FFFD95854F4](RtlUserThreadStart+0x34)
...

deprecate pvCopy.h?

I'm considering deprecating it in pvDataCPP for removal after 8.0.0. As usage of pvCopy.h seems to be limited to pvDatabaseCPP, perhaps this code should be migrated into pvDatabaseCPP? I have no immediately pressing reason to do so. This is more about reducing public API size in the longer term.

I've never been clear on what problem(s) this code is trying to solve. I have the impression that it involves a situation which I avoided in QSRV by giving every client the exact same Structure.

@mrkraimer Would you like to make a case for keeping this code in pvDataCPP?

anyscalar.h: ... break strict-aliasing rules

../../src/misc/pv/anyscalar.h: In member function 'void epics::pvData::PVScalarValue<T>::getAs(epics::pvData::AnyScalar&) const [with T = float]':
../../src/misc/pv/anyscalar.h:113: warning: dereferencing pointer '<anonymous>' does break strict-aliasing rules
../../src/misc/pv/anyscalar.h:113: note: initialized from here

As this has come up twice (by @dirk-zimoch ), I want to document the outcome.

This warning is (so far) only seen of GCC versions near 4.4.x. Neither older, nor newer, compilers are complaining (eg. gcc 6.3.0 doesn't). As long as this remains the case, and no mis-behavior is observed (eg. from testanyscalar), then I don't intent to take any action. Concerned users can build with -fno-strict-aliasing.

Global ctor ordering causes crashes

@MarkRivers reports

I rebuilt the windows-x64-static architecture with HOST_OPT=NO so I could get a stack trace in the example application.  Here it is:

>          test.exe!epicsMutex::lock()  Line 273 + 0x5 bytes     C++
           test.exe!epics::pvData::Lock::Lock(epicsMutex & m={...})  Line 45 + 0x46 bytes  C++
           test.exe!epics::pvData::FieldCreate::getFieldCreate()  Line 1459 + 0x12 bytes        C++
           test.exe!epics::pvData::getFieldCreate()  Line 1230  C++
           test.exe!epics::pvData::PVDataCreate::PVDataCreate()  Line 358 + 0x23 bytes     C++
           test.exe!epics::pvData::PVDataCreate::getPVDataCreate()  Line 617 + 0x21 bytes            C++
           test.exe!epics::pvData::getPVDataCreate()  Line 1656          C++
           test.exe!epics::pvAccess::`dynamic initializer for 'pvDataCreate''()  Line 58 + 0x1a bytes   C++
           test.exe!_initterm(void (void)* * pfbegin=0x000000013f6ada00, void (void)* * fend=0x000000013f6adf48)  Line 873        C
           test.exe!_cinit(int initFloatingPrecision=1)  Line 301            C
           test.exe!__tmainCRTStartup()  Line 262 + 0xa bytes            C
           test.exe!mainCRTStartup()  Line 189 C
           kernel32.dll!00000000775259cd()    
            [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]         
           ntdll.dll!000000007775a561()            ''

In epicsMutex::lock this=0. 

That is called from this code in lock.h
    explicit Lock(Mutex &m)
    : mutexPtr(m), locked(true)
    { mutexPtr.lock();}

In that code the debugger tells me that "m id=???", Error CXX0030 Expression cannot be evaluated.

This is Visual Studio 2010.

Migrate Requester, Monitor, and related types to pvAccess

As was discussed on the 15th, I'd like to migrate some classes/interfaces from the pvData* modules into pvAccess*. For the C++ code this is specifically the following types currently defined in requester.h and monitor.h.

epics::pvData::Requester
epics::pvData::RequesterPtr
epics::pvData::MessageType
epics::pvData::getMessageTypeName
epics::pvData::MonitorElement
epics::pvData::MonitorElementPtr
epics::pvData::MonitorElementPtrArray
epics::pvData::Monitor
epics::pvData::MonitorRequester

The migration plan for C++ would be to first introduce aliases into the epics::pvAccess namespace. Which allow either name to be used by dependent modules. This does not require any changes to pvDataCPP.

namespace epics { namespace pvAccess {
using epics::pvData::Requester;
}}

The next step would move the headers, and swap the namespaces and aliases. This also maintains API compatibility, but introduces potentially complex module version dependencies.

The final step is to remove the aliases from the epics::pvData namespace.

This should be split over at least 2 "major" releases. The second step could go on either side of this "split".

I'm still investigating possible ways to do a phased migration. If I (or others) can't find anything, then it would be necessary to have an API break.

getSubField returns "nullptr" is not helpful and does not allow chaining of methods

element->pvStructurePtr->getSubField<PVDouble>("value.myDouble")->put(13434.454);

Since getSubField returns nullptr instead of throwing an exception, this fails in a very bad way if typo in fieldName(server gets stuck somewhere and it spins without crashing.)

Truncation in BitSet::or_and()

For "this |= set1 & set2" the result size should be "max(this, min(set1, set2))" while previously it was "min(set1, set2)" resulting in truncation if the LHS is longer than the RHS.

Practically this can lead to truncation of the overflow bit set, clearing bits which were previously set.

As the fix is straightforward I've already pushed d4292d8 along with an added test case.

The bug was present in the initial implementation.

Serialization and alignment trouble, part 3

In looking to extend CI testing to RTEMS I find that testByteByffer is failing with 4.10 (passes with 4.9). A prime example of why we should be running tests for embedded targets more often.

The failure seen is:

testByteBuffer.tap ........ 1/? 
not ok 95 - buf.getPosition()==16

Printing some additional detail shows this to be:

testByteBuffer.tap ........ 1/? 
not ok 95 - buf.getPosition() (12) == 16 (16)

Investigating further. For at least RTEMS4.10 + pc386, the root cause seems to be that malloc() can return a pointer aligned only to 4 bytes. The test is checking for at least 8 byte alignment. The implementation of ByteBuffer::align() assumes this.

I'm don't know yet if this has any practical implications. Both 4.9 and 4.10 pass with a mvme3100 emulator, but this could be a coincidence.

cf. #54 #65

Buffer overflows during serialization

Today @shengb and I were troubleshooting a crash of the masarService. The crash appeared first in a memcpy() in DefaultPVArray::serialize() due to an obviously corrupt 'space_for'. Further investigation showed that the byteBuffer involved had _position >> _limit so that getRemaining() returned a negative value cast to size_t. This was happening in a PVA send thread.

We changed PVUnionArray::serialize() to flush after serializing each element. This avoids a crash, and suggests to me that there are some missing ensureBuffer() calls. I see immediately that DefaultPVArray::serialize() calls SerializeHelper::writeSize() with no check to see that space is available. There may be others.

shared_vector begin()/end()==NULL offends MSVC

It seems that the MSVC implementation of some STL requires that iterators never be NULL. This triggers an issue as shared_vector<> uses raw pointers as iterators, and gives NULL for an empty array.

@MarkRivers reports that this trigger copious assertion dialogs.

  	testSerialization.exe!std::_Debug_message(const wchar_t * message=0x000000013f813048, const wchar_t * file=0x000000013f813080, unsigned int line=3049)  Line 15	C++
 	testSerialization.exe!std::_Debug_pointer<unsigned char>(const unsigned char * _First=0x0000000000000000, const wchar_t * _File=0x000000013f813080, unsigned int _Line=3049)  Line 692	C++
 	testSerialization.exe!std::equal<unsigned char const * __ptr64,unsigned char const * __ptr64>(const unsigned char * _First1=0x0000000000000000, const unsigned char * _Last1=0x0000000000000000, const unsigned char * _First2=0x0000000000000000)  Line 3051	C++
 	testSerialization.exe!epics::pvData::`anonymous namespace'::compareArray<unsigned char>(const epics::pvData::PVValueArray<unsigned char> * left=0x000000000028ade0, const epics::pvData::PVValueArray<unsigned char> * right=0x00000000002889d0)  Line 159 + 0x4c bytes	C++
 	testSerialization.exe!epics::pvData::`anonymous namespace'::compareField(const epics::pvData::PVScalarArray * left=0x000000000028ade0, const epics::pvData::PVScalarArray * right=0x00000000002889d0)  Line 202 + 0x15 bytes	C++
 	testSerialization.exe!epics::pvData::operator==(const epics::pvData::PVField & left={...}, const epics::pvData::PVField & right={...})  Line 339 + 0xf bytes	C++
 	testSerialization.exe!`anonymous namespace'::testEquals()  Line 162 + 0x35 bytes	C++
 	testSerialization.exe!main(int __formal=1, int __formal=1)  Line 875	C++
 	testSerialization.exe!__tmainCRTStartup()  Line 278 + 0x19 bytes	C
 	testSerialization.exe!mainCRTStartup()  Line 189	C
 	kernel32.dll!00000000775259cd() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!000000007775a561() 	

In this instance std::equal() asserts that the third argument is not NULL.

header files in pv/ sub-directories

At present all header files are installed in a pv/ sub-directory which does not exist in the source tree(s). This is inconvenient as it complicates the configuration of (at least) qtcreator to avoid accidentally editing installed header files which will be overwritten (QtC warns about this, but it's still annoying).

Would there be any objection to moving all header files into pv/ sub-directories in the source tree? That is, creating a pv/ directory in every source directory containing header files.

This would not effect the layout of installed files, and therefore not be user visible.

PVUnion::set(UNDEFINED_INDEX, NULL) fails for discriminating union

Due to a logic error, calling set w/ UNDEFINED_INDEX on a discriminating union tried to call getField(-1), which throws an out of range exception.

Immutable not working correctly

According to the issue in pvDatabase (see here) setImmutable does not actually work. It appears the issue lies in PVScalarValue::put.

Currently it is like below:

  /**
   * Put a new value into the PVScalar.
   * @param value The value.
   */
  inline void put(typename storage_t::arg_type v) {
    storage.store(v);
    PVField::postPut();
  }

This seems to fix the issue.

  /**
   * Put a new value into the PVScalar.
   * @param value The value.
   */
  inline void put(typename storage_t::arg_type v) {
    if (!isImmutable()) {
      storage.store(v);
    }
    PVField::postPut();
  }

I would suggest to throw an exception here if it is immutable, just letting it silently ignore the put operation is probably dangerous. I was thinking something like below.

    /**
     * Put a new value into the PVScalar.
     * @throws std::runtime_error if the field is immutable
     * @param value The value.
     */
    inline void put(typename storage_t::arg_type v) {
        if(isImmutable()){
            throw std::runtime_error("Cannot perform put operation - field is immutable");
        }
        storage.store(v);
        PVField::postPut();
    }

Would this be acceptable?

Mismatched docs/implementation for getField

The documentation for Structure::getField(size_t) and Union::getField(size_t) claim that they return a null pointer if the index is not valid. The implementation throws a out_of_range exception instead (from vector::at).

Also, Union::getField(size_t) returns FieldConstPtr but Structure::getField(size_t) returns const FieldConstPtr &. I think both should return FieldConstPtr for consistency.

Structure:

pvDataCPP/src/pv/pvIntrospect.h

Lines 734 to 740 in cd24363

	/**
	* Get the field for the specified fieldName.
	* @param index The index of the field to get;
	* @return The introspection interface.
	* This will hold a null pointer if the field is not in the structure.
	*/
	const FieldConstPtr& getField(std::size_t index) const {return fields.at(index);}

Union:

pvDataCPP/src/pv/pvIntrospect.h

Lines 857 to 863 in cd24363

	/**
	* Get the field for the specified fieldName.
	* @param index The index of the field to get;
	* @return The introspection interface.
	* This will hold a null pointer if the field is not in the union.
	*/
	FieldConstPtr getField(std::size_t index) const {return fields.at(index);}

Deprecate PVDisplay and friends?

Following the discussion for epics-base/pva2pva#24. I had a look for places where display.format is referenced in this module. This led to my looking at a corner of the repo which I've never used. IMO these "helpers" aren't helpful.

Is anyone using them?

Either directly, or indirectly through normativeTypesCPP? If not I'll mark them deprecated for removal after the next release. Also the places where they are exposed by normativeTypesCPP.
I'll migrate the pieces which are being used to normativeTypesCPP.

This covers some, or all, of the following.

Headers:

• pv/alarm.h
• pv/control.h
• pv/display.h
• pv/timestamp.h
• pv/pvAlarm.h
• pv/pvControl.h
• pv/pvDisplay.h
• pv/pvEnumerated.h
• pv/pvTimeStamp.h

Classes:

• AlarmSeverityFunc
• AlarmStatusFunc
• Alarm
• Control
• Display
• TimeStamp
• PVAlarm
• PVControl
• PVDisplay
• PVEnumerated
• PVTimeStamp

Note. If you go searching, be careful not to confuse pvAlarm.h and class PVAlarm here with PvAlarm.h and class PvAlarm in pvaPy. The pvaPy code is doing the same thing, but doesn't seem to depend on these helpers.

testTypeCast.tap: 8-bit integers printed as non-printing characters

The testTypeCast.tap file from APS Jenkins build server contains a number of instances of 8-bit integers being printed as characters.

In particular a (u)int8_t with 1 is printed as ascii 0x1 = start of heading (SOH).

Note: The latest Jenkins build reports TAP parse errors in this file and the build is being subsequently marked as unstable. This may be related to the non-printing characters. There are 13 SOHs in the tap file and 13 exceptions in the parsing.

(De)Serialization triggers alignment fault on RTEMS/powerpc

Till Straumann reports https://bugs.launchpad.net/epics-base/+bug/1754787

We experienced a (reproduceable) crash of pvData on RTEMS/powerpc.

I tracked it down to the ByteBuffer (de-)serialization code which
does IMHO ugly things:

class ByteBuffer {
  char *position;

  ...

  template <typename T>
  inline void put(T value)
  {
    ...
    *((T*)position) = value;
  }
};

PLEASE: don't code like this.

The template was instantiated for a 'double' value and -- since this is a 'byte buffer' -- it is obvious that the 'position' pointer does not meet any alignment constraints.

The PowerPC (and possibly other machines, too) cannot store floating-point registers to unaligned addresses and the type cast invites the compiler to generate inappropriate code (claiming that 'position' is a valid 'double*' which in fact is not necessarily true).

During compilation I had also seen several 'breaking strict alias rule' warnings flying by (albeit not for this particular code, of course) -- but after seeing the above code I would recommend to study such warnings carefully.

sharedVector compile problem in MSVC

Hello
I try to use MSVC compiler v143, v142 or v140 to achieve a client which uses lib pvaClient on windows 10, but the class sharedVector reported errors C7683 and C2860, unable to create reference to void, it looks like MSVC has some big differences with g++, any idea fixes this problem?

because of some special reason on Windows, I could only use MSVC. MinGW is work but lacks of other libraries.

LP: #2029482 — pvget json error

In LP: #2029482 Matt Clark reports that pvget -M json doesn't print fields containing NaN values and generates an error "Error in monitor handler : yajl_gen_invalid_number" instead.

The simplest fix would be for the json formatter to just output json5 (available when pvDataCPP is built against 7.0.6.1 or later), in which case the patch I posted to the LP bug above implements that.

A possible alternative would be to add a separate -M json5 formatter option which enables the json5 option; properly supporting NaNs and Infinity in regular json would require converting them as strings.

Check for unsafe use of getSubField()

Check for unsafe uses of getSubField() by testing for null and handling appropriately (returning null, throwing an exception, error status as appropriate) or using getSubFieldT().

Field sub-class comparison is incomplete

When the specializations BoundedScalarArray, FixedScalarArray, and BoundedString were added, the comparisons (operator==) were not updated. So only the element/scalar type is to decide on type equivalence.

I'm not sure what the technical effects of this omission are, but given that no code seems to use these it's minor.

createRequest: always fails after first failure

If a call to createRequest->create fails then all following requests can also fail.
This is fixed in
https://github.com/mrkraimer/pvDataCPP

A pull request should be created sometime soon and this will also be fixed.

Repeat doxygen comments in pvAlarm.h

While trying to understand the pvData API I came across a duplicate doxygen comment in the PVAlarm header file.

    //default constructors and destructor are OK
    //returns (false,true) if pvField(is not, is) a valid alarm structure
    //An automatic detach is issued if already attached.
    /*
     * Attach to a field of a PVData object.
     * @param pvField The pvField.
     * @return (false,true) if the pvField (is not, is) an alarm structure.
     */
    /*
     * Attach to a field of a PVData object.
     * @param pvField The pvField.
     * @return (false,true) if the pvField (is not, is) an alarm structure.
     */
    bool attach(PVFieldPtr const & pvField);

Small issue I know, but I thought worth mentioning.

BitSet serialization error for MSB

When I discovered my mistakes in #22 I did what we should all do, which is write test code. In the process I discovered a nasty little bug with serialization of BitSet. As an optimization the high element is serialized as bytes.

Unfortunately, in the case where a bit is set in the high byte of the high word, and the number of bytes to be serialized is a multiple of 8, the logic of serialize() calls putByte() eight times (LSB first) while deserialize() calls getLong() once. On little endian systems this makes no difference, but on big endian systems this is backwards.

To avoid a wire protocol compatibility break on LE systems the fix will almost certainly be to change deserialize().