I can't agree with you on this. You first say a bit is either 0 or 1, which is not true for a signed bit (0 or -1), and confirms somehow we should use unsigned here. A good compiler should also complain about setting 1 to something that can only take 0 or -1, and we did that before this commit. The unambigous solution would be to use the bool type, but that's another story, and the closest alternative is to use *unsigned* bit field of size 1.
BTW, I can revert this since the code using it does not compare the bit explicitely, but I find signed bit fields quite error prone if the value is not meant to be used for signed things (which isn't the case here). On Fri, Jun 20, 2014 at 1:51 PM, Jim Jagielski <j...@jagunet.com> wrote: > Besides that, any compiler worth its salt should complain. > > On Jun 20, 2014, at 7:50 AM, Jim Jagielski <j...@jagunet.com> wrote: > >> Who does that w/ bit fields? You either check if it's >> true/false or you use the expected bit operations. >> >> On Jun 19, 2014, at 9:29 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >>> On Thu, Jun 19, 2014 at 2:59 PM, Jim Jagielski <j...@jagunet.com> wrote: >>>> >>>> On Jun 19, 2014, at 8:43 AM, yla...@apache.org wrote: >>>> >>>>> Author: ylavic >>>>> Date: Thu Jun 19 12:43:05 2014 >>>>> New Revision: 1603863 >>>>> >>>>> URL: http://svn.apache.org/r1603863 >>>>> Log: >>>>> Use unsigned bit flags (otherwise the non-zero value to be used is -1). >>>>> >>>> >>>> I don't understand that at all... A bit is either 1 or 0. >>>> >>> >>> Well, it depends on what you are doing with that bit... >>> >>> #include <stdio.h> >>> int main(int argc, const char *argv[]) >>> { >>> struct { >>> int s:1; >>> } bitfield; >>> >>> bitfield.s = 1; >>> if (bitfield.s > 0) { >>> printf("positive\n"); >>> } >>> else { >>> printf("negative or nul\n"); >>> } >>> if (bitfield.s == 1) { >>> printf("one\n"); >>> } >>> else { >>> printf("not one\n"); >>> } >>> >>> return 0; >>> } >>> >>> $ ./bitfield >>> negative or nul >>> not one >>> >> >
