2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Bug: #1790723 and Bug #1790715 |
From: | Ralph Lange <[email protected]> |
To: | "Williams Jr., Ernest L." <[email protected]> |
Cc: | EPICS Core Talk <[email protected]>, "Straumann, Till" <[email protected]> |
Date: | Wed, 26 Sep 2018 15:41:32 +0200 |
Hi Ralph,
Now, that CloudBees is back in business.
I was hoping to pick up fixes for the following issues:
Are these still under review?
https://bugs.launchpad.net/epics-base/+bug/1790723
https://bugs.launchpad.net/epics-base/+bug/1790715
Until and including 3.15 -- (I didn't look at 3.16) the parameter string '@<parameter>' was an optional part of hardware link fields. In V7 this no longer seems to be the case dbStaticLib:2320: if (parm && pinfo->ltype != RF_IO) { /* move parm string to beginning of buffer */ memmove(pinfo->target, parm, len + 1); } else if (!parm && pinfo->ltype == RF_IO) { /* RF_IO, the string isn't needed at all */ free(pinfo->target); ...
We have a standard solution for differing setsockopt argument sizes, see the typedefs in libcom/ src/osi/ os/*/osdSock. h and the section above in client/udpiiu.cpp It might be Okay to re-use osiSockOptMcast Loop_t since it probably has the same size on all targets, but for safety's sake I would probably define a new typedef.
Cheers,
Ernest