5 ms·

Kind of a tangent, but I found: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/muxes/i2c-mux-ltc4306.c?id=HEAD#n63 https:/

Kind of a tangent, but I found: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/muxes/i2c-mux-ltc4306.c?id=HEAD#n63 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg) { return (reg == LTC_REG_CONFIG) ? true : false; } Oh man, c'mon. That kind of thing bugs me. Just "return reg == LTC_REG_CONFIG" already, sheesh. (And maybe make it a preprocessor directive while you're at it?)

vlovich123 5y ago
Int-> bool conversion is something that MSVC complained about (C4800) for the longest time for some kind of obscure reason. Wouldn’t surprise me if this code was written against a longer that had a similar warning OR that maybe this code is shared with their Windows driver and this needs to compile on both (at least that’s my attempt at finding the most generous explanation for that).
- carapace 5y ago
  Sorry, what int -> bool conversion?
  - testrun 5y ago
    parameter reg is int, return value is bool.
    - NavinF 5y ago
      “reg == LTC_REG_CONFIG” is a bool. There’s no conversion going on here.
      - zargon 5y ago
        In the C language, the result of the equality operator is an int, not a bool.
        carapace 5y ago
        Ah, whale oil beef hooked, you're right. > The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int. For any pair of operands, exactly one of the relations is true. https://port70.net/~nsz/c/c11/n1570.html#6.5.9p3 https://port70.net/~nsz/c/c11/n1570.html#6.5.9p3 Thanks for clearing that up. (Although I feel a bit foolish now.)
        xorcist 5y ago
        It's not really an explanation though. It's how the language should work. That ternary operator "?" is just an if-statement which should have the same "problem" with an int argument. It is a broken compiler that would complain about an if statement but an identical ?-statement. If the int nature of equals-to was a problem, you'd have to use limit its use to switch statements.
        zargon 5y ago
        There's no problem with the "int argument". (Not sure if you mean the function argument ("reg") or the operand of the conditional operator, but either way not a problem.) The conflict is between the declared return type of the function and the type of the returned expression.
        xorcist 5y ago
        Right, but the same could be said for the ternary operator.
        zargon 5y ago
        I don't follow. What could be said about it?
        xorcist 5y ago
- CamperBob2 5y ago
  That reminds me of one of my favorite footguns: void foo(bool bar) { } int main(void) { foo("Whose bright idea was this?"); } No error, not even a warning, perfectly legit code. If bar had been declared int or char, you'd get an error. Instead, your code ends up less safe because you used bool, thinking you were doing the right thing. Yes, they wanted to allow it anywhere a conditional expression would fit, but implicit conversion from anything other than int and char would have been a good place to draw the line. So I wouldn't be surprised if the GP example was prompted by a similar design flaw in either the language or a particular compiler.

vlovich123 5y ago

Int-> bool conversion is something that MSVC complained about (C4800) for the longest time for some kind of obscure reason. Wouldn’t surprise me if this code was written against a longer that had a similar warning OR that maybe this code is shared with their Windows driver and this needs to compile on both (at least that’s my attempt at finding the most generous explanation for that).

carapace 5y ago
Sorry, what int -> bool conversion?
- testrun 5y ago
  parameter reg is int, return value is bool.
  - NavinF 5y ago
    “reg == LTC_REG_CONFIG” is a bool. There’s no conversion going on here.
    - zargon 5y ago
      In the C language, the result of the equality operator is an int, not a bool.
      - carapace 5y ago
        Ah, whale oil beef hooked, you're right. > The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence. Each of the operators yields 1 if the specified relation is true and 0 if it is false. The result has type int. For any pair of operands, exactly one of the relations is true. https://port70.net/~nsz/c/c11/n1570.html#6.5.9p3 https://port70.net/~nsz/c/c11/n1570.html#6.5.9p3 Thanks for clearing that up. (Although I feel a bit foolish now.)
        xorcist 5y ago
        It's not really an explanation though. It's how the language should work. That ternary operator "?" is just an if-statement which should have the same "problem" with an int argument. It is a broken compiler that would complain about an if statement but an identical ?-statement. If the int nature of equals-to was a problem, you'd have to use limit its use to switch statements.
        zargon 5y ago
        There's no problem with the "int argument". (Not sure if you mean the function argument ("reg") or the operand of the conditional operator, but either way not a problem.) The conflict is between the declared return type of the function and the type of the returned expression.
        xorcist 5y ago
        Right, but the same could be said for the ternary operator.
        zargon 5y ago
        I don't follow. What could be said about it?
        xorcist 5y ago
CamperBob2 5y ago
That reminds me of one of my favorite footguns: void foo(bool bar) { } int main(void) { foo("Whose bright idea was this?"); } No error, not even a warning, perfectly legit code. If bar had been declared int or char, you'd get an error. Instead, your code ends up less safe because you used bool, thinking you were doing the right thing. Yes, they wanted to allow it anywhere a conditional expression would fit, but implicit conversion from anything other than int and char would have been a good place to draw the line. So I wouldn't be surprised if the GP example was prompted by a similar design flaw in either the language or a particular compiler.