#34 get of record subfield succeeds (with surprising results)

[Dave Hickin]

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)

[Dave Hickin]

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

[Ralph Lange]

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.

Sorry, but I do not find this bug report as exceptionally clear as others might.

[Dave Hickin]

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.

[Ralph Lange]

Moved to GitHub (pvaSrv Issue #8).