| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: dbGetPdbAddrFromLink dropped from 3.15 again |
| From: | Michael Davidsaver <[email protected]> |
| To: | Till Straumann <[email protected]> |
| Cc: | EPICS Techtalk <[email protected]> |
| Date: | Thu, 2 Aug 2018 21:02:26 -0700 |
On 07/31/2018 01:16 PM, Till Straumann wrote: > I'm running into the same issue that was discussed here: > > https://epics.anl.gov/tech-talk/2017/msg01247.php > > Michael's answer (https://epics.anl.gov/tech-talk/2017/msg01268.php) > recommends replacing subRecord by aSubRecord -- however, my use case > rather fits the first scenario mentioned by Michael: avoiding the overhead of dbGet() > > What is the recommended migration path for this case? Can you give some more details? How do you use the dbAddr* which was being returned? > I guess I could use > > dbGetNelements(const struct link*) > dbGetLinkDBFtype(const struct link*) > > to make sure the target of my link matches the expectations -- but there is > no way to access the data the link points to without either making a copy > (dbGet) or exploiting internals (which is deprecated/discouraged) > > :-( > > Like other posters I'm looking for a minimally intrusive (and yet 'safe') solution > for a legacy system with not much horse-power. > > - Till