Choices field incorrect for menu and device fields. WAS: get of record subfield succeeds (with surprising results)

[ralphlange]

From Dave Hickin <david.hickin_AT_diamond.ac.uk>:

If you do a pvget with the channel name equal to a field of a v3 record (with pvaSrv being used) then the get succeeds.

Sometimes the result is a scalar:

$ eget -i -r "value" ColorMode.RTYP
ColorMode.RTYP
epics:nt/NTScalar:1.0
string value mbbo

Other times the field value is converted to an enum using the choices of the PV (i.e.ZRST etc):

$ caget -n ColorMode.DTYP
ColorMode.DTYP 3
$ eget -i ColorMode.DTYP
ColorMode.DTYP
epics:nt/NTEnum:1.0
enum_t value
int index 3
string[] choices [Mono,RGB1,RGB2,RGB3]

So the results can be surprising:

$ eget Acquire.RTYP Acquire.PINI Acquire.DISS Acquire.DISA
Acquire.RTYP busy
Acquire.PINI Done
Acquire.DISS Done
Acquire.DISA 0
$ eget Acquire.DTYP
Segmentation fault (core dumped)

[ralphlange]

From Dave Hickin <david.hickin_AT_diamond.ac.uk>:

Matej has fixed the eget seg fault issue so an eget to the above fields now gives:

$eget adImSrv:sim:Acquire.RTYP ... adImSrv:sim:Acquire.DTYP
adImSrv:sim:Acquire.RTYP busy
...
adImSrv:sim:Acquire.DTYP 2

[ralphlange]

Does that mean the bug is fixed?

The two first issues you are describing do look not completely random to me, given that .RTYP is a string and .DTYP is an enum.
The choices seem to be from a different field, though. Is that the bug you want to report?

If it is about the eget tool segfaulting, I am not sure I am the right owner of the ticket.

[ralphlange]

From Dave Hickin <david.hickin_AT_diamond.ac.uk>:

Yes, it appears that the issue is that for a channel to a record field with enumerated type other than a VAL field the value.index correctly gets the index from the field, but the value.choices gets the values from the VAL field.

[dhickin]

I've retitled this with something more meaningful now I understand what's happening.

For channels to DBF_MENU and DBF_DEVICE fields of a record whose VAL field is a DBF_ENUM the "value.choices" field is being filled in with the strings for the VAL field. For 3.14 this is fixed for example by testing the DBF type against DBF_ENUM.

.

For 3.15 there is the additional problem that dbChannelFinalFieldType() returns the DBR type instead of the DBF type (#17) . I'll treat that separately in that issue.