Re: graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type

On Sat, 17 Aug 2013 11:24:41 +0100
David Chisnall <theraven_at_FreeBSD.org> wrote:

> On 17 Aug 2013, at 10:48, "O. Hartmann" <ohartman_at_zedat.fu-berlin.de>
> wrote:
> 
> > port graphics/blender doesn't compiler neither in CURRENT nor
> > 9.2-PRE for the moment. On CURRENT (FreeBSD 10.0-CURRENT #4
> > r254430: Fri Aug 16 23:23:08 CEST 2013 amd64), compilation fails
> > with the belwo shown error message - for roughly a month now. 
> > 
> > I think this is dur to some issues of inconsistency/incompatibility
> > of the math.h/cmath headers regarding the reported c++11 issues.
> > 
> > 
> > Since port graphics/blender doesn't compile on 9.2 nor does it
> > compile in CURRENT and the fact that the math.h isn't fixed in the
> > 9.2-RELEASE as I was told, the port should be marked broken.
> > 
> > 
> > 
> > [ 55%] Building C object
> > source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o
> > [ 55%] Building C object
> > source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.c.o /usr/ports/graphics/blender/work/blender-2.68/source/blender/imbuf/intern/cineon/cineonlib.c:280:70:
> > error: controlling expression type 'unsigned int' not compatible
> > with any generic association type if (cineon->element[i].refLowData
> > == CINEON_UNDEFINED_U32 || isnan(cineon->element[i].refLowData))
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/math.h:118:19: note:
> > expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf,
> > __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note:
> > expanded from macro '__fp_type_select' #define __fp_type_select(x,
> > f, d, ld) _Generic((x),    
> 
> This looks like a correct error.  isnan(unsigned int) is undefined
> behaviour in C or C++.  Now, we have a hard error instead of doing
> something random.  This change was made it make it easier to find
> logic errors at compile time, and it seems to be doing exactly that
> here: now the port fails to build, rather than building and having
> undefined behaviour.
> 
> David
> 

Hello David.

Thank you very much for this insight.

As I understand it for now, the math.h/cmath behaviour is as expected by
defintion an correct so far in FreeBSD? If yes, it would imply that the
port graphics/blender is broken then. In the latter case the blender
developers should be correct this upstream, shouldn't they?

Again, thank you very much and for the patience explaining it again.

Regards,
Oliver