epics-base/normativetypescpp

normativeTypesCPP is an EPICS V4 C++ module

normativetypescpp's Issues

NTNDArrayAttributeBuilder's tags field is not being properly reset

NTNDArrayAttributeBuilder's tags field is being ignored inside the reset method. This is causing generated NTNDArrayAttribute's to randomly contain or not the tags field, triggering epics-base/pvAccessCPP#40 issue for me.

PVNTField::createAlarmLimit() implementation.

I cannot find an implementation for this function.

Unchecked calls to getField(), getSubField(), etc.

This module needs to be audited for unchecked calls to methods which can return NULL. This is especially problematic in the isCompatible() methods which are intended to be used on suspect type definitions.

normativeTypesCPP/src/ntndarray.cpp

Line 352 in 5e151c3

StructureArrayConstPtr attributeField = structure->getField<StructureArray>( "attribute");

cf. areaDetector/ADCore#296

Missing LICENSE and COPYRIGHT files

From Andrew Johnson <anj_AT_aps.anl.gov>:

Module is missing LICENSE and COPYRIGHT files which are referred to in source code header comments within the module

Compiler warnings: non-virtual destructor

normativeTypesCPP/include/pv/ntndarrayAttribute.h:40: warning: 'class epics::nt::detail::NTNDArrayAttributeBuilder' has virtual functions but non-virtual destructor
normativeTypesCPP/include/pv/ntattribute.h:40: warning: 'class epics::nt::detail::NTAttributeBuilder' has virtual functions but non-virtual destructor

These trigger warnings in all downstream modules every time the above headers are included.

Move from travis-ci.org to GHA and Appveyor

Needs converting to use ci-scripts and config files for the other CI services adding.

isCompatible() considered harmful

Fixing isCompatible() is proving quite tedious because of code like the following. note the field[3], which is asserting not just the existence of string 'display.field', but that it is the 4th of 5 fields.

This makes even the slightest change to the display substructure a compatibly break, and would tie my hands wrt. replacing 'display.format'!

Given this, and the grief caused by returning false with no indication of which test has failed, I'm inclined to stub the is*() methods to always return true. Code calling methods documented to return NULL really should be checking for this case (though I know this is often not done).

normativeTypesCPP/src/ntfield.cpp

Lines 130 to 134 in 2d186d4

	f = fields[3];
	if(names[3].compare("format")!=0) return false;
	if(f->getType()!=scalar) return false;
	s = static_pointer_cast<const Scalar>(f);
	if(s->getScalarType()!=pvString) return false;

"nt" is not a good name for the generated library

This tag introduces ambiguities and is misleading.

I thought this was a Windows configuration mixup when the pvAccess build did not find "libnt.a".
There is also a number theory library that uses the same name.

This will start creating serious trouble when making binary packages, as the package manager will complain, and Linux distributions do not like these name clashes at all.

Given that library names can use an arbitrary number of arbitrary characters, we should be able to find something more unique.