Comment 12 for bug 1824277

An input link currently has no knowledge of the field to which its data is going to be written. In some cases (e.g. the printf record) there *is* no such field in the record, and the code reading the link may pass a different pointer on each call to getValue() — think double-buffering of arrays for example. The printf record passes a pointer to an auto variable on the stack, and the data type it requests can also vary because it depends on the format string in the FMT field. Thus when an INP field itself gets a new constant value the generic code in dbPutLinkValue() can have no way to know where to put that value. As a result we *cannot* implement a generic solution for this in the core IOC code (dbAccess.c).

The calcout record type was probably the first to implement the technique of making its INP fields special(SPC_MOD) and calling recGblInitConstantLink() from the special() routine; the other synApps records were developed following its example. Keeping that technique working is what this bug is all about — we broke it between 3.15 and 3.16. It does require help from the record to implement though, so if we like this behavior and want it to spread we just have to modify the other record types to do it. Doing that is outside the scope of this bug-fix.

I described an alternative approach earlier (have a constant link's getValue() method return the new value once), but that would still require changes to the record types, and thinking about it further it would cause interesting effects to any record type that uses double-buffering, so I don't recommend this approach. This would also fall outside the scope of this bug-fix.