4 ms·

int i = 0; // nullptr dereference int ub = (int)i; It is implementation defined I think, not UB. 0 could be a valid address

int i = 0; // nullptr dereference int ub = *(int*)i; It is implementation defined I think, not UB. 0 could be a valid address

shadowgovt 2y ago
I believe you are correct as per a summary at https://stackoverflow.com/questions/60147025/is-converting-an-integer-to-a-pointer-always-well-defined https://stackoverflow.com/questions/60147025/is-converting-a...
- compiler-guy 2y ago
  That summary talks about creating a nullptr out of an int, but not dereferencing it. And, in fact, takes care to note that dereferencing the created pointer is invalid.
  - shadowgovt 2y ago
    But using an invalid pointer is implementation-dependent, not UB, unless I'm missing a step here?
    - compiler-guy 2y ago
      https://en.cppreference.com/w/cpp/language/pointer https://en.cppreference.com/w/cpp/language/pointer Nullptr section is not directly linkable, but: "A pointer whose value is null does not point to an object or a function (the behavior of dereferencing a null pointer is undefined), and compares equal to all pointers of the same type whose value is also null."
      - shadowgovt 2y ago
        `p = reinterpret_cast<int*>(42);` doesn't create a nullptr.
        compiler-guy 2y ago
        The gp example does, however.
    - int_19h 2y ago
      It is UB in ISO C23 (6.5.4.2/4). I'm pretty sure there's equivalent verbiage in ISO C++.
jcranmer 2y ago
An integer constant expression with value 0 is guaranteed to convert to a null pointer (in fact, the "null pointer constant" was traditionally defined to be precisely that). But an integer with value 0 that's not an integer constant expression can potentially be legally a pointer value which is not a null pointer. Which means, confusingly, that it is legal for this to print true: if (((void*)0) != (void*)(0, 0)) puts("true"); (Conversion between integers and pointers is a lot less well-specified than many people suspect, and that's before people start pondering provenance.)
deleted 2y ago
[deleted]
compiler-guy 2y ago
The conversion is well defined, so the creating a pointer with `(int *) 0` is fully legal, but the dereference itself is UB. https://en.cppreference.com/w/cpp/language/nullptr https://en.cppreference.com/w/cpp/language/nullptr https://en.cppreference.com/w/cpp/language/pointer https://en.cppreference.com/w/cpp/language/pointer Nullptr section is not directly linkable, but: "A pointer whose value is null does not point to an object or a function (the behavior of dereferencing a null pointer is undefined), and compares equal to all pointers of the same type whose value is also null."
- shadowgovt 2y ago
  This is where I get a bit lost in the spec, I think... Can the compiler know that the value of `i` is 0? If yes, then the spec says regardless of how the implementation defines nullptr, assigning literal 0 to a pointer variable is assigning a nullptr (i.e. the compiler must turn `0` into whatever the nullptr is in the underlying implementation). If no, then 0 is just some unknown value and the assignment gives you an implementation-dependent (not necessarily invalid) pointer to whatever address `0` means on this architecture.
  - int_19h 2y ago
    The C spec only requires that integer constant expressions that have zero value are nullptrs. The moment you assign it to an int variable, it's no longer a constant expression as far as the language is concerned, so if you then cast that int variable to a pointer, the result is indeterminate. (Note also that in C, unlike C++, "const" really means that it is read-only, not that it is a constant expression, so that doesn't change anything.) However, even if the resulting pointer is not a null pointer, dereferencing it is still UB unless it points at a valid C object. So if the compiler can statically prove that for this architecture, there's no valid C object at that address (e.g. because the compiler itself never produces code that would result in objects placed at that address), it can still treat it as UB, same as dereferencing a literal 0.
    - shadowgovt 2y ago

int i = 0; // nullptr dereference int ub = *(int*)i; It is implementation defined I think, not UB. 0 could be a valid address

shadowgovt 2y ago

I believe you are correct as per a summary at https://stackoverflow.com/questions/60147025/is-converting-an-integer-to-a-pointer-always-well-defined https://stackoverflow.com/questions/60147025/is-converting-a...

compiler-guy 2y ago
That summary talks about creating a nullptr out of an int, but not dereferencing it. And, in fact, takes care to note that dereferencing the created pointer is invalid.
- shadowgovt 2y ago
  But using an invalid pointer is implementation-dependent, not UB, unless I'm missing a step here?
  - compiler-guy 2y ago
    https://en.cppreference.com/w/cpp/language/pointer https://en.cppreference.com/w/cpp/language/pointer Nullptr section is not directly linkable, but: "A pointer whose value is null does not point to an object or a function (the behavior of dereferencing a null pointer is undefined), and compares equal to all pointers of the same type whose value is also null."
    - shadowgovt 2y ago
      `p = reinterpret_cast<int*>(42);` doesn't create a nullptr.
      - compiler-guy 2y ago
        The gp example does, however.
  - int_19h 2y ago
    It is UB in ISO C23 (6.5.4.2/4). I'm pretty sure there's equivalent verbiage in ISO C++.

jcranmer 2y ago

An integer constant expression with value 0 is guaranteed to convert to a null pointer (in fact, the "null pointer constant" was traditionally defined to be precisely that). But an integer with value 0 that's not an integer constant expression can potentially be legally a pointer value which is not a null pointer. Which means, confusingly, that it is legal for this to print true: if (((void*)0) != (void*)(0, 0)) puts("true"); (Conversion between integers and pointers is a lot less well-specified than many people suspect, and that's before people start pondering provenance.)

deleted 2y ago

[deleted]

compiler-guy 2y ago

The conversion is well defined, so the creating a pointer with `(int *) 0` is fully legal, but the dereference itself is UB. https://en.cppreference.com/w/cpp/language/nullptr https://en.cppreference.com/w/cpp/language/nullptr https://en.cppreference.com/w/cpp/language/pointer https://en.cppreference.com/w/cpp/language/pointer Nullptr section is not directly linkable, but: "A pointer whose value is null does not point to an object or a function (the behavior of dereferencing a null pointer is undefined), and compares equal to all pointers of the same type whose value is also null."

shadowgovt 2y ago
This is where I get a bit lost in the spec, I think... Can the compiler know that the value of `i` is 0? If yes, then the spec says regardless of how the implementation defines nullptr, assigning literal 0 to a pointer variable is assigning a nullptr (i.e. the compiler must turn `0` into whatever the nullptr is in the underlying implementation). If no, then 0 is just some unknown value and the assignment gives you an implementation-dependent (not necessarily invalid) pointer to whatever address `0` means on this architecture.
- int_19h 2y ago
  The C spec only requires that integer constant expressions that have zero value are nullptrs. The moment you assign it to an int variable, it's no longer a constant expression as far as the language is concerned, so if you then cast that int variable to a pointer, the result is indeterminate. (Note also that in C, unlike C++, "const" really means that it is read-only, not that it is a constant expression, so that doesn't change anything.) However, even if the resulting pointer is not a null pointer, dereferencing it is still UB unless it points at a valid C object. So if the compiler can statically prove that for this architecture, there's no valid C object at that address (e.g. because the compiler itself never produces code that would result in objects placed at that address), it can still treat it as UB, same as dereferencing a literal 0.
  - shadowgovt 2y ago