On 12/20/2017 01:29 AM, Eric Botcazou wrote:
If some port maintainer used 1 <= x && x <= 24 style and doesn't like
x >= 1 && x <= 24 for some reason, there is always IN_RANGE macro and
IN_RANGE (x, 1, 24) can be used instead (though, such a change requires
double checking the type of x, it should
> That depends on the reader, and as we have multiple readers, it is better to
> be consistent. And, I find no ambiguity on IN_RANGE, it is
> inclusive for both values and used heavily through the compiler, so using it
> is a welcome cleanup, e.g. some ports that use it most often:
OK, let's go f
On Wed, Dec 20, 2017 at 09:29:22AM +0100, Eric Botcazou wrote:
> > If some port maintainer used 1 <= x && x <= 24 style and doesn't like
> > x >= 1 && x <= 24 for some reason, there is always IN_RANGE macro and
> > IN_RANGE (x, 1, 24) can be used instead (though, such a change requires
> > double c
> If some port maintainer used 1 <= x && x <= 24 style and doesn't like
> x >= 1 && x <= 24 for some reason, there is always IN_RANGE macro and
> IN_RANGE (x, 1, 24) can be used instead (though, such a change requires
> double checking the type of x, it shouldn't be wider than HOST_WIDE_INT).
Yes,
On Tue, 19 Dec 2017, Jakub Jelinek wrote:
> Hi!
>
> Segher's comment in one of the PRs
> ('-- We don't use "yoda conditions" in GCC ("0 == x");')
> I was looking at led me discover we have more Yoda conditions in the source
> than healthy.
>
> This patch fixes the comparison order to the usual s
