INP link reading from array (size 1) yields 0

[Ralph Lange]

From Jueri Tagger <jtagger _AT_ bnl.gov>:

I tested 3.15.4-pre1 for the issue with waveforms having length 1.

The behavior is still the same: Consider 3 records below:

record(ai, "$(user):AI") {
  field(VAL, "1")
  field(PINI, "YES")
  field(FLNK, "$(user):WF1")
}
record(waveform, "$(user):WF1") {
  field(FTVL, "DOUBLE")
  field(NELM, "1")
  field(INP, "$(user):AI")
  field(FLNK, "$(user):calcout")
}
record(calcout, "$(user):calcout") {
  field(CALC, "A")
  field(INPA, "$(user):WF1")
}

With base 3.14 the 3rd record, calcout, gets VAL=1 whereas with 3.15 the calcout VAL remains 0.
Do you have a good explanation?

[Ralph Lange (ralph-lange)]

Verified using a minimal db on a softIoc:

record(waveform, "wf") {
  field(FTVL, "DOUBLE")
  field(NELM, "1")
  field(FLNK, "co")
}
record(calcout, "co") {
  field(CALC, "A")
  field(INPA, "wf")
}

While 3.14 always fetches correctly the waveform's element, 3.15 consistently fetches 0.

[mdavidsaver (mdavidsaver)]

Candidate fix and test case committed to 3.15 branch (12752).

The issue is that the condition in dbDbGetValue() to select use of direct field access vs dbGet() is testing 'paddr->special != SPC_ATTRIBUTE'. I've added an additional test of "paddr->special != SPC_DBADDR". Is the SPC_ATTRIBUTE test necessary?

[Ralph Lange (ralph-lange)]

Excellent. This works as expected.

Note: Please use the "--fixes=lp:12345" argument when committing a bug fix, as this makes issue tracking easier.

[Andrew Johnson (anj)]

On 05/01/2016 12:41 PM, mdavidsaver wrote:
> Is the SPC_ATTRIBUTE test necessary?

dbGet() has special code for fetching the values of record-type
attributes such as RTYP. Whether we actually need to use that code
(given that each attribute has an associated field descriptor) may be a
different question that would take some investigation to answer.

On examination of this code I see that attributes are a pin-hole in our
record locking scheme, given that they store a per-record-type value,
not per-record-instance. I think the assumption was that their values
would get set at startup and never changed afterwards, but we don't have
anything in the code to enforce that. I know that I-Tech use them in
their Libera IOCs but I don't know if they ever change their values at
runtime. However since the "field" address doesn't change even when you
change the value and they store a fixed-length string, I don't see this
as a big problem, at worst a client would get a mixture of old and new
string values.

- Andrew

--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say."
-- Edward Snowdon

[mdavidsaver (mdavidsaver)]

So I think the answer to my question is that 'paddr->special != SPC_ATTRIBUTE' isn't strictly necessary, but doesn't a bug either.

> On examination of this code I see that attributes are a pin-hole in our
record locking scheme

Splitting this discussion off as lp:1577761