Re: (0 <= i && i < N) is not "backwards"

[Noah Lavine]

Hello,

To continue a tangent, if adding an explicit isnan() makes the code run any slower, I think you should file a bug with GCC to get that fixed.

In general, I really dislike the idea of adjusting coding style to work around a compiler's limitations. If the compiler is broken, I think it's best to fix it and move on.

Thanks,
Noah Lavine

On Mon, Mar 25, 2013 at 10:53 AM, Eli Zaretskii <address@hidden> wrote:

> Date: Mon, 25 Mar 2013 07:35:51 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden

>
> On 03/25/2013 01:20 AM, Eli Zaretskii wrote:
>
> > Out of fairness, you introduced this style into Emacs sources
>
> I've certainly used it in the changes I made, and as a result it's
> become more popular, but I did not introduce it.  That style has
> been used in Emacs, as a minority style, for many years.

AFAIR, it was once a negligible minority at best, so much so that I
don't remember it being used.  That was in the days that the only
style enforced in the Emacs sources was what the GNU Coding Standards
say, btw.  That's what allowed "minority styles" in the first place.

> > If we want our code to be robust in the face of NaNs, we should
> > probably use 'isnan' explicitly
>
> That will slow the code down and make it harder to read.

I disagree; there's nothing unclear in a call to isnan, and the
slow-down is negligible, if it exists at all, and won't be noticed in
the context of Emacs, which doesn't pretend to be a fast
number-cruncher anyway.

> Perhaps a
> comment could be introduced; but must we really add a comment
> "watch out for NaNs!" every time we have a floating point comparison?

Such comments would be even worse.

But the problem with relying on 0 < foo is that most people won't even
consider the subtle difference between that and !(foo >= 0) when NaNs
are involved.  Calling isnan makes that explicit.

Anyway, this issue is tangential to the style issue.