Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
- Subject: Re: Strange behavior of -Wfloat-equal on clang (Xcode 5)
- From: Asiga Nael <email@hidden>
- Date: Fri, 03 Jan 2014 18:28:29 +0000 (GMT)
> El Viernes 3 de enero de 2014 18:24, Fritz Anderson <email@hidden> escribió:
>
> >On 3 Jan 2014, at 7:46 AM, Asiga Nael <email@hidden> wrote:
> > [...]
> > From more tests I did, it seems -Wfloat-equal doesn't trigger a warning if one
> > operand is a floating point literal that can be casted to a integer exactly
> > without data loss.
> >
> > However, compiled it with llvm-gcc mytest.c -Wfloat-equal and all three tests
> > generate a warning (which is the behavior I'm used too).
> > [...]
>
> This is the intended behavior. The only way to get the warnings you're used to is
> to compile your own clang and use that.
> [...]
> If the purpose of compilation warnings is to alert the programmer to the potential
> for _actual_ misbehavior at run time; and not to alert when no potential exists;
> then clang's behavior is correct.
>
> Comparison to exact representations has no potential for misbehavior.
First of all, I don't understand why a==2.1 triggers the warning and a==2.0 doesn't. Why is 2.0 safer than 2.1? If 2.0 is a safe comparison, then 2.1 would be too.
I thought the reason for -Wfloat-equal is that comparing two floats for equality is always unsafe, no matter if such floats can have an exact integral representation or not.
Consider this example: Let's imagine a math application allows you to do some computations on unit vectors, which aren't available when the vector length isn't the unit. The application needs to check the vector length against 1.0. Doing it using the == operator is unsafe (a vector resulting from a lot of math won't exactly equal 1.0 even if it can be legitimately called a unit vector).
Another example: a decremental loop with a floating point counter, with the end condition set to equal 0.0 (the loop would be unsafe, as it could get out of bounds depending on the implementation).
I cannot think of any safe examples when comparing floats to exact constants.
I admit however, I get some annoying false positives when I compile with gcc, because sometimes I compare floats against 0.0 just for the sake of knowing if I can safely divide by them or not. In such scenario, I don't care if the number is close to zero, I just want to be confident that I can do 1/a without raising a math exception (and, btw, maybe they aren't false positives, because I'm not sure if a float which isn't exactly equal to 0.0 can be used as denominator with a certain guarantee that it doesn't generate infinity: maybe a very close to zero value can become infinity when used as denominator... I'm not sure about this).
Thanks a lot for your reply, although I don't understand the reasoning driving clang to consider a==2.1 unsafe but a==2.0 safe.
asiga
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden