The first split vote about C compiler random test

I think the problem is that -3 < 1 but -3 > 1U because the -3 is "promoted" (quietly corrupted) to UINT_MAX - 2 (edit: C99 guarantees this value). So the question is whether a small unsigned bitfield is handled like a signed int (which can represent all its possible values) or an unsigned int (which is more like what you asked for).

It's just astounding how many developer-years have been wasted by the industry's insistence on producing and accepting wrong answers when commodity hardware has been maintaining under/overflow flags for literally my entire career.

It is a requirement of the C standard that objects with static storage duration are initialised to a "zero of the appropriate type" (which eg. means NULL for pointers). In most implementations this can take advantange of the BSS section (which is why the requirement came about in the first place), but it's required to work even on eg. MS-DOS.

For the second part of your comment, comparisons are always done between the same type. In this case, either the -3 is promoted to unsigned (which gives the result UINT_MAX - 2, a large positive number) or the bitfield is promoted to int. It is the rules for this type promotion that is the heart of the problem.

The problem is that if you try to rewrite that example to avoid the comma operator, you either have to duplicate the update_thing(&foo) call, as in:

  update_thing(&foo);
  while (foo != 0) {
      /* loop body */

      update_thing(&foo);
  }

Unnecessary duplication like this is itself a potential source of bugs - it's all to easy to update one but not the other. The other alternative is to hack up the loop to exit in a strange place:

  while (1) {
      update_thing(&foo);
      if (foo == 0)
          break;

      /* loop body */
   }

This is arguably even worse - the actual loop termination condition is not where you expect to find it anymore. Personally, I find the formulation using the comma operator to be completely clear.

Note that the bug referenced here is more about the subtleties of bitfield type promotion in expressions, and the interplay of bitfields with operators that evaluate to the type of one of their arguments, than it is about the comma operator. You can show the same bug using the assignment operator instead of the comma operator.

If you're going consign anything involved here to the "never do this" section, I'd start with any use of bitfields, and maybe also include mixing unsigned and signed types in expressions without explicit conversion.

Well, the problem here is (assuming I'm understanding everything correctly) pretty specifically the combination of the comma operator and a bitfield. Of those two, I'd say the latter, even if superficially more intuitive, is probably the more obscure and advisable to avoid.

The comma operator, while not all that common, can be pretty useful in common situations, and can easily achieve both clarity and conciseness. For example, to iterate over a singly-linked list while keeping a pointer to the previous item:

  for (prev = NULL, this = first; this != NULL; prev = this, this = this->next) {
    ...
  }

I think this is a perfectly reasonable way to do things. Disallowing the comma operator due to an underspecified interaction with bitfields would be throwing out the baby with the bathwater, in my opinion.