Another possibility I see for adding direct access to the TIME field while avoiding the drawback of keeping additional fields up to date is, like in the first proposal, to handle it similar to SPC_DBADDR. But instead of using a public field that would need to be updated after every processing, use a private filed inside dbCommonPvt. This field would only be updated when needed; as far as I can tell the appropriate time is whenever SPC_SBADDR is handled. Specifically, dbEntryToAddr() would, instead of calling the record's cvt_dbaddr(), convert epicsTimeStamp to UINT64 and return a pointer to that as DBADDR.
Does this make sense? The way I see it, that's the only way to access the value of the waveform, and thus should be sufficient as the only way to access the converted value of the timestamp. Is my understanding correct?
Another possibility I see for adding direct access to the TIME field while avoiding the drawback of keeping additional fields up to date is, like in the first proposal, to handle it similar to SPC_DBADDR. But instead of using a public field that would need to be updated after every processing, use a private filed inside dbCommonPvt. This field would only be updated when needed; as far as I can tell the appropriate time is whenever SPC_SBADDR is handled. Specifically, dbEntryToAddr() would, instead of calling the record's cvt_dbaddr(), convert epicsTimeStamp to UINT64 and return a pointer to that as DBADDR.
Does this make sense? The way I see it, that's the only way to access the value of the waveform, and thus should be sufficient as the only way to access the converted value of the timestamp. Is my understanding correct?