Wrong name [LWN.net]

Wrong name

Posted Jan 17, 2008 12:25 UTC (Thu) by NAR (subscriber, #1313)
In reply to: Wrong name by ms
Parent article: A kernel security hole

Once again, this bug is simply a result of relying on a prehistoric language.

I'm afraid it's not. I agree that C could be improved with a bitfield type like this:

bitfield accessMode {
  bit open;
  bit write;
  ...
};

but wrongly named variables of same types would still lead to these kind of errors.

(Log in to post comments)

Wrong name

Posted Jan 17, 2008 12:29 UTC (Thu) by ms (subscriber, #41272) [Link]

No no. The problem is these parameters should not have the same type.

Wrong name

Posted Jan 17, 2008 13:06 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

They could be changed to enumerated types, but that wouldn't automatically help much because
conversion between integer and enumerated types is implicit in C. Perhaps sparse would have
caught it though.

Wrong name

Posted Jan 17, 2008 14:28 UTC (Thu) by nix (subscriber, #2304) [Link]

It could have been made more obvious, and thus more likely to be rapidly spotted, by making
sure that FMODE_WRITE and MAY_WRITE had different *values* which overlapped with something
quite different in the other flag: but if that had been thought of, this bug would never have
happened because people would have been paying extra attention to it anyway.

Wrong name

Posted Jan 17, 2008 16:17 UTC (Thu) by tbellman (guest, #49983) [Link]

Except that it wouldn't have helped.  The buggy code used FMODE_WRITE to check the bit in the
variable 'flag'; the correct code uses MAY_WRITE to check the bit in the variable 'acc_mode'.
The buggy code did use the correct access mechanisms for the variable it looked at, so no
amount of BDSM type control would have helped.

Wrong name

Posted Jan 17, 2008 13:06 UTC (Thu) by guus (subscriber, #41608) [Link]

C already supports bitfields:

struct accessMode {
    int open:1;
    int write:1;
    ...
};

Bitfields

Posted Jan 17, 2008 14:57 UTC (Thu) by zlynx (subscriber, #2285) [Link]

But the kernel doesn't appear to use bitfields much.  I seem to remember that it's something
to do with GCC and miserable performance on non-x86 arch's.