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

On 17 Aug 2013, at 15:39, "O. Hartmann" <ohartman_at_zedat.fu-berlin.de> wrote:

> 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?

Yes, I believe (and am willing to be convinced otherwise by test cases) that we now accept anything that the standard allows and reject with a compile-time error things that are undefined behaviour.

From the tiny snipped of code in the error message, my guess would be that refLowData is something that is read from a file (header?) as an unsigned int and is supposed to be a float here, and so needs a cast via a union (or just a *(float*)& if strict aliasing is not turned on).

David