On Tue, Jun 26, 2012 at 6:41 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 26 June 2012 19:25, Blue Swirl <blauwir...@gmail.com> wrote: >> On Tue, Jun 26, 2012 at 6:11 PM, Peter Maydell <peter.mayd...@linaro.org> >> wrote: >>> On 26 June 2012 18:58, Blue Swirl <blauwir...@gmail.com> wrote: >>>> On Mon, Jun 25, 2012 at 7:38 PM, Peter Maydell <peter.mayd...@linaro.org> >>>> wrote: >>>>> +static inline uint64_t field64(uint64_t value, int start, int length) >>>> >>>> start and length could be unsigned. >>> >>> They could be, but is there any reason why they should be? >>> set_bit(), clear_bit() etc use 'int' for bit numbers, so this >>> is consistent with that. >> >> Negative shifts don't work, the line with assert() would get shorter >> and simpler and I like unsigned values. > > I don't like using unsigned for numbers that merely happen to always > be positive (as opposed to actually requiring unsigned arithmetic)[*], > so I think I'll stick with being consistent with the existing bitops > functions, thanks :-)
Using unsigned types also produces better code in some cases. There are also operations which do not work well with signed integers (%, >>). > > [*] the classic example of where that kind of thing can trip you up > is the way it complicates the termination condition on a "for (i = N; > i >= 0; i--)" decreasing loop. > > -- PMM