Thanks. I will adjust accordingly. On Fri, May 31, 2019, 02:26 Martin Sebor <mse...@gmail.com> wrote:
> On 5/30/19 12:58 AM, Aldy Hernandez wrote: > > Hi. > > > > We have zero_p in the API, but we don't have non_zero_p. Instead we use > > a non-API function range_is_nonnull. I've fixed this. > > > > I have also gotten rid of the duplicity of using the non-API > > range_is_null in favor of value_range_base::zero_p(). > > > > Furthermore, there's value_range*::set_null and > > value_range*::set_nonnull(). It's inconsistent to use null/nonnull as > > well as zero/non_zero throughout. I've moved everything to *zero. > > With the -Wformat-diag cleanup still fresh in my memory, I can't > help but point out that the GCC spelling convention calls for > "nonzero" vs "non-zero" or "non zero". > > Naming the function set_nonzero() would be in line with both > the convention and established practice (over 2000 instances) > and set_non_zero would not be (only 22 instances of non_zero > in GCC sources). > > This, of course, is in contrast to things like bit-field and > built-in where the convention calls for the hyphen but where > in code we seem to prefer "bitfield" nonetheless ;-) (Names > like get_bit_field_ref_def and bit_field_size being > the exceptions). > > Martin > > > > > Finally, it seems to me that the derived value_range versions of > > set_*zero/null are a bit confusing in that they clear equivalences > > behind the scenes. There's no intuitive reason why setting a range of > > [0,0] versus [5,10] should clear equivalences. I've made the > > equivalence nuking explicit in the handful of places where we do this, > > and thus reduced the need for separate value_range versions. > > > > I believe with these changes, as well as the pending intersect patch, > > we've cleaned up the remaining value_range uses where we actually wanted > > to use value_range_base. Or at least the remaining "value_range tem" > > business. > > > > OK? > > > > Aldy > >