Re: EPICS 3.14.12.3 Build Problems with the new Ubuntu 16.04 LTS

[Torsten Bögershausen <torsten.bogershausen@esss.se>]

On 27/04/16 17:28, Andrew Johnson wrote:
> On 04/27/2016 10:06 AM, Michael Davidsaver wrote:
> > So strictly speaking Base should never have depended on this behavior.
> > In fact beginning with Base 3.15.0.1, and soon to be included in
> > 3.14.12.5, it does not.
> >
> > http://bazaar.launchpad.net/~epics-core/epics-base/3.14/revision/12486
> >
> > Given that newer versions of Base will build, and that this change has
> > already found its way into an Ubuntu LTS release, I don't think it's
> > worth pursuing another change to glibc.
> According to the Linux manpage, finite() was originally a BSD
> floating-point classification function which takes a double. There were
> equivalents available for float and long double with different names.
> All the epicsMath.h code is trying to do is ensure that we provide a
> definition of finite(), using isfinite() where it exists. I see no
> reason to check GLIBC versions, we don't need it to be that efficient.
>
> I am committing this change to the 3.14 branch, so it will appear in the
> forthcoming 3.14.12.6 release:
>
>   #ifdef isfinite
>   #  undef finite
> -#  define finite(x) isfinite(x)
> +#  define finite(x) isfinite((double)x)
What happens if we have someting in the syle

finite(y + z)

In other words, I think that the "x" deserves () around it:
+# define finite(x) isfinite((double)(x))