Code review comment for ~anj/epics-base/+git/base-7.0:fix-1824277

There should be no change to the behavior of writing to the related value field, which for the calcout isn't marked as special although it is pp so doing so does trigger record processing. Nothing in that chain of processing has been touched though, it's only dbPutFieldLink() that I've modified, the routine that handles puts to a link field. However I just added a couple of testdbPutFieldOk() calls, writing to the two input-value fields that have const INP links.

The fix may slightly alter the code path taken anytime something writes to a link field at runtime, ai.INP fields included, but in most cases there should be no change to the result. It is unusual for a link field to be marked special, and in Base the calcout is the only type which has any special links.

There are a few references to PV_LINK in the epics-modules repo's, but I think you're right that most code won't normally see plink->type == PV_LINK; the only time that should happen with this fix is in a dsxt::add_record() routine where the link type in the device() entry in the DBD file is given as CONSTANT (which means "or DB/CA/PV/JSON LINK").

The bug hasn't affected many users because there hasn't been a release of synApps for EPICS 7 yet, and it's the synApps users who will see and complain about it. Keenan Lang is working to release synApps 6.1 by the end of May (see his question at https://github.com/epics-modules/iocStats/issues/33#issuecomment-484995327), but I don't know if that is intended to support EPICS 7 — synApps 6.0 was aimed at Base-3.15.5. If we're planning to merge other major changes after 7.0.2.2 that could preclude us putting out a patch release for this bug-fix unless we start a release branch.

I understand this seems like a rush, but a synApps release strikes me as a good reason to try and get this fix included.