Re: Bug: #1790723 and Bug #1790715

[Ralph Lange <ralph.lange@gmx.de>]

Hi Ernest,

As far as I can see, the status information in the Launchpad issue tracker is up to date and should answer your questions.

Cheers,

~Ralph

On Tue, 25 Sep 2018 at 20:10, Williams Jr., Ernest L. <ernesto@slac.stanford.edu> wrote:

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

Bug #1790723 “Database HW link parameter string no longer option...” : Bugs : EPICS Base

bugs.launchpad.net

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);      ...

https://bugs.launchpad.net/epics-base/+bug/1790715

Bug #1790715 “rsrv: failed to set mcast ttl 1” : Bugs ...

bugs.launchpad.net

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