[Verse-dev] About NAN and various REAL_MAX

[Emil Brink]

eskil at obsession.se wrote:
> Hi
> 
> If we keep the MAT_FOLAT reserved what is the point of changing the 
> network protocol to NAN?

NAN is more correct, it is what we mean. We don't want to make a legal
floating point value impossible to send, we want to be able to express
that a floating point field is currently *not* holding a floating point
value, and use that fact to signal command aliasing. NAN seems to be a
good match for that need.

> NAN is substantially easier to send by mistake. 

It might be, but probably not a specific NAN. I'm not sure though, as I
don't know how the processor picks the bit pattern to use for NAN if it
occurs during ordinary maths operations. I wonder if anybody does. :)

> Also we talked about receiving one NAN, you are testing for all of them.

Huh? No I'm not, I'm testing for exactly one bit pattern, since I do not
use the isnan() function. Read the mail again.

Come to think of it, perhaps we could do a similiar approach if we had
to resort to just reserving an actual floating point number, by figuring
out the bit pattern for the desirable number, and then creating a pre-
processor symbol to match. Might be possible, but I consider it worse.

> This is not a platform problem this is a compiler problem. I would much 
> rather see a ifdef solution then a include solution.

Uh? Not sure I follow there ... Could you be a bit more specific? How can
we ifdef around this?

Regards,

/Emil