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
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 style.
If some port maintainer used 1 <= x && x <= 24 style
