3 ms·

I know that's the case for ints, but in this case [0] the int was cast to a boolean, which I thought would ensure comparisons would perform as expected, but no

• gpderetta 4y ago
  You are not casting an int to a bool (which would indeed do the right thing) but casting a pointer to int to a pointer to bool which violates strict aliasing.
  • sk0g 4y ago
    Ah fair, thanks for pointing it out! Wasn't my issue, just the minimal reproduction of behaviour that happened over a few external modules, causing this issue.
  • jstimpfle 4y ago
    This is not strict aliasing as far as I understand. Strict aliasing is about inference of distinctness of pointers. The case here is that an invalidly typed pointer is created (a bool pointer pointing to where there is no bool). Not sure what this situation is called in standardese.
    • gpderetta 4y ago
      The type aliasing rule is also known as the strict aliasing rule, see for example: https://en.cppreference.com/w/c/language/object https://en.cppreference.com/w/c/language/object
      • jstimpfle 4y ago
        After skimming this, I still think the strict aliasing rule is used by compiler to avoid re-reads. What you were talking about is probably something else, maybe an "invalid lvalue access" as per your link.
        • gpderetta 4y ago
          From cpp reference: "Strict Aliasing: Given an object with effective type T1, using an lvalue expression (typically, dereferencing a pointer) of a different type T2 is undefined behavior, unless [non relevant exceptions omitted]". In this case the expression has type bool and the underlying object has type int, so it is a straightforward strict aliasing violation. With GCC you can compile with -fno-strict-aliasing to ignore this rule. But now you fall afoul of the rule that prevents accessing an invalid representation (i.e. a trap-representation) of an object. This rule is also described in the link I posted before, under the object representation paragraph.
          • jstimpfle 4y ago
            ok, so in the case above, it's both (if strict aliasing is active). Makes sense now.
  • bobbyi 4y ago
    The strict aliasing violation is incidental. You can change int8_t to char in the code and get the same result with no strict aliasing violation.
    • gpderetta 4y ago
      Sure, as per my other comment, it then would be an object representation violation. Even ignoring both rules, there is still no reason to expect the assertion not to fire: int x = 2; assert(*(bool*)x == true); This is the same as: float x = 2.0 assert(*(int*)x == 2); Just because two object are convertible, there is no reason to expect their representation to be the same.