> .. the type stored in 'plink->value.pv_link.pvt' changed from 'DBADDR*' to 'dbChannel*' back with Base 3.15.0.1. ..
It’s another Friday, and I just ran into a related issue with a very old sub-record setup.
The genSub record which supports array outputs probably already existed, but that legacy implementation used a plain sub record and then hacked that by peeking into waveform records behind inputs links to
use them as outputs.
So it casts the value.pv_link.pvt into a 'DBADDR*’, a basic check of the ->name looks fine, but then strange things happen …
Thanks to Michael for mentioning it here!
From:
Core-talk <core-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
Date: Friday, June 14, 2024 at 8:45 PM
To: EPICS core-talk <core-talk at aps.anl.gov>
Subject: [EXTERNAL] dblsr code question/challenge
A little C code "challenge" which puzzled me today.
Why was the following change a no-op?
As background. For DB_LINK, the type stored in
'plink->value.pv_link.pvt' changed from 'DBADDR*'
to 'dbChannel*' back with Base 3.15.0.1. I was
quite surprised to notice that dblsr() was still
treating it as a 'DBADDR*'.I initially assumed
that no one had tested it since then. But, after
thinking for awhile, I realized that the
situation was not so simple.
> --- a/modules/database/src/ioc/db/dbLock.c
> +++ b/modules/database/src/ioc/db/dbLock.c
> @@ -918,7 +918,7 @@ long dblsr(char *recordname,int level)
> pdbFldDes = pdbRecordType->papFldDes[pdbRecordType->link_ind[link]];
> plink = (DBLINK *)((char *)precord + pdbFldDes->offset);
> if(plink->type != DB_LINK) continue;
> - pdbAddr = (DBADDR *)(plink->value.pv_link.pvt);
> + pdbAddr = &((dbChannel *)(plink->value.pv_link.pvt))->addr;
https://urldefense.us/v3/__https://github.com/epics-base/epics-base/commit/72d50ce2749bbc791907a32c1ed77af1333a21f5__;!!G_uCfscf7eWS!bqiRBiT_Ip0nrcLGxrmm1ZE6yiy1TzCcEIkBjZ30UI_daWaDnRhBenpKVMd1dyXCfbUXcYySljDXqZ16jZH7AIP8Qg$
... my answer below ...
My key to understanding was noticing that the only usage
of 'pdbAddr' is to print the record name:
> printf(" %s\n",pdbAddr->precord->name);
Now the most obvious answer would be if the struct dbAddr
embedded in the struct dbChannel were the first member.
However, this is not the case.
> typedef struct dbChannel {
> const char *name; /**< Channel name */
> dbAddr addr; /**< Pointers to record & field */
> ...
The first member of dbAddr is the record pointer:
> typedef struct dbAddr {
> struct dbCommon *precord; /* address of record */
So
> pdbAddr->precord->name
was actually accessing dbChannel::name with the correct
number of indirections (1) because 'precord->name' is not
actually an indirection since the first member is a 'char[]'.
> typedef struct dbCommon {
> char name[61]; /**< @brief Record Name */
> ...
So, I wasn't entirely truthful in calling this a no-op.
If a DB_LINK were targeted at a record alias name, then
between 3.15.0.1 and now, dblsr() would print the alias
instead of the intended canonical record name.
Now for the weekend!
