Re: Replacement for dbGetPdbAddrFromLink ?

["Dunning, Michael" <mdunning@slac.stanford.edu>]

Hi Michael,
Thanks for the background info.  In my case, I think it's the latter:
working around limitations of subRecord.  But we're hesitant to
completely rewrite the code because it's very old and very extensive.

Is there any reason to suspect that defining the macro as I have would
not work presently, or break in the future?

Thanks again.




Michael Dunning
SLAC National Accelerator Laboratory
Accelerator Research Division Test Facilities
2575 Sand Hill Road, MS 63
Menlo Park, CA 94025
+1 (650) 926-5200


On Wed, Aug 9, 2017 at 6:29 AM, Michael Davidsaver
<mdavidsaver@gmail.com> wrote:
> Are these usages about avoiding an array copy in dbGet(), or working
> around the limitations of subRecord?  In the second cause I would
> suggest to look at aSubRecord.
>
>
> dbGetPdbAddrFromLink() was removed (by me) because it exposed an
> internal implementation detail of links.  These internals change prior
> to 3.15.0.1, again in 3.16.1, and perhaps again in future.
>
> https://github.com/epics-base/epics-base/commit/74b24bbe0fd1015f13af0d70e39289efd32fd7c9
>
>
> Historically Base has exposed a lot of structures and functions which
> were not really intended/expected to be public APIs.  This makes
> maintaining or using Base all the more difficult as it isn't clear what
> was intended to be public API vs. what has become defacto public over
> the years.  Some breakage is inevitable when attempting to bring some
> order to this chaos.
>
>
>
> On 08/08/2017 10:25 PM, Stubbs, Scott A. wrote:
>> Hi, I would be interested in this as well.  We have an IOC talking to an
>> MKS RGA which also uses this macro:
>>
>>     /* Get the pointer to the record in INPB.
>>    * Is this a valid pv? If so, then verify that data type is double,
>> and check that it's a waveform.
>>    */
>>   pAddr= dbGetPdbAddrFromLink(&psub->inpc);
>>   if(!pAddr|| (pAddr->field_type != DBF_DOUBLE) || (pAddr->no_elements
>> == 1))
>>     return(ERROR);
>>
>>   /* Create an array of 2 pointers */
>>   pdev = (intArrayOut_ts *)calloc(sizeof(intArrayOut_ts),1);
>>   if(!pdev)
>>   {
>>     recGblRecordError(S_rec_outMem,(void*)psub,"sub: init_record");
>>     return(ERROR);
>>   }
>>
>>   /* Set the private data information */
>>   pwf  = (waveformRecord *)pAddr->precord;
>>   pdev->preadings = (double*)pAddr->pfield; /* ptr to data <DEVICE>:IVB */
>>   pdev->pnord = &pwf->nord;                  /* ptr to # of wf items     */
>>   pdev->nelem = pAddr->no_elements;          /* max number of data
>> elements in record   */
>>
>> Thanks,
>> Scott
>> ---
>> Scott Stubbs
>> LCLS Controls & Data Systems
>> sstubbs@slac.stanford.edu <mailto:sstubbs@slac.stanford.edu>
>>
>>
>>
>>
>>> On 4 Aug 2017, at 12:43 pm, Dunning, Michael
>>> <mdunning@slac.stanford.edu <mailto:mdunning@slac.stanford.edu>> wrote:
>>>
>>> I'm failing to come up with a clever way of replacing
>>> dbGetPdbAddrFromLink, which was removed in base 3.15.  It was defined
>>> as a macro in dbAccessDefs.h as this:
>>>
>>> #define dbGetPdbAddrFromLink(PLNK) \
>>> ( ( (PLNK)->type != DB_LINK ) \
>>> ? 0 \
>>> : ( ( (struct dbAddr *)( (PLNK)->value.pv_link.pvt) ) ) )
>>>
>>>
>>> I can redefine this macro in my source code as the above, but is there
>>> a better way of replacing its functionality, perhaps with a different
>>> macro or function call?
>>>
>>> Here's an example of how we were using it:
>>>
>>> ...
>>> DBADDR *cntAddr = dbGetPdbAddrFromLink(&psub->inpi);
>>> short *cntP;
>>> long cntNord, offset;
>>> struct rset *prset;
>>>
>>> if (!cntAddr) return -1;
>>> dbScanLock(cntAddr->precord);
>>> if ((cntAddr->field_type == DBF_SHORT) && ((prset =
>>> dbGetRset(cntAddr)))) {
>>>    cntP = (short *)cntAddr->pfield;
>>>    if (!cntP) cntNord = 0;
>>>    else (*prset->get_array_info)(cntAddr, &cntNord, &offset);
>>> } else {
>>>    cntP    = 0;
>>>    cntNord = 0;
>>> }
>>> dbScanUnlock(cntAddr->precord);
>>> ...
>>>
>>>
>>> This is for some rather critical systems, so we're trying at all costs
>>> to avoid surprise runtime errors.
>>>
>>> Any suggestions are much appreciated.
>>>
>>> Mike
>>>
>>>
>>>
>>> Michael Dunning
>>> SLAC National Accelerator Laboratory
>>> Accelerator Research Division Test Facilities
>>> 2575 Sand Hill Road, MS 63
>>> Menlo Park, CA 94025
>>> +1 (650) 926-5200
>>
>