Experimental Physics and Industrial Control System

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
> [email protected] <mailto:[email protected]>
> 
> 
> 
> 
>> On 4 Aug 2017, at 12:43 pm, Dunning, Michael
>> <[email protected] <mailto:[email protected]>> 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
> 

Replies:

Re: Replacement for dbGetPdbAddrFromLink ? Dunning, Michael

References:

Replacement for dbGetPdbAddrFromLink ? Dunning, Michael

Re: Replacement for dbGetPdbAddrFromLink ? Stubbs, Scott A.

Navigate by Date:

Prev: Re: Replacement for dbGetPdbAddrFromLink ? Stubbs, Scott A.

Next: agilent 34972a Pierrick Hanlet

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: Replacement for dbGetPdbAddrFromLink ? Stubbs, Scott A.

Next: Re: Replacement for dbGetPdbAddrFromLink ? Dunning, Michael

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024