5 ms·

>modern C++ is already secure enough Why to have nullptr dereferencing? Why to have an undefined behavior on option<> dereferencing? Why to have dangling refs?

>modern C++ is already secure enough Why to have nullptr dereferencing? Why to have an undefined behavior on option<> dereferencing? Why to have dangling refs? Why not to check borrow possibility statically? God, we don't event have a decent and safe variant (sum) type in c++. Adding all that (unnecessary) complexity c++ has (how many whatever-values and initializations does it have?). It is unsafe as hell, and lots of stuff could be made safer trivially in a new language (say, rust or F*).

zaarn 9y ago
Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option<> is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
- ernst_klim 9y ago
  Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option<> is handled as None instead of Some What? How could NULL be treated as Some?
  - steveklabnik 9y ago
    It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
    - zaarn 9y ago
      I was actually using mut/const and got this bug, I don't think I used &T since I was handling raw memory addresses.
      - steveklabnik 9y ago
        Hm, then I don't know what happened, as I just checked and it's definitely not doing the optimization, as it shouldn't! If you can reproduce you should file a bug.
        zaarn 9y ago
        It might help to know that I was writing an UEFI application, so basically kernel mode. Otherwise, I've redesigned the affected subsystem so I'm not sure I could reproduce the behaviour
  - zaarn 9y ago
    NULL is still a valid memory address, which in this case I had to use. When packing such an address into a mut or const within a Option<>, a NULL will be treated like a None when you write, essentiall, Some(NULL).

zaarn 9y ago

Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option<> is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).

ernst_klim 9y ago
Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option<> is handled as None instead of Some What? How could NULL be treated as Some?
- steveklabnik 9y ago
  It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
  - zaarn 9y ago
    I was actually using mut/const and got this bug, I don't think I used &T since I was handling raw memory addresses.
    - steveklabnik 9y ago
      Hm, then I don't know what happened, as I just checked and it's definitely not doing the optimization, as it shouldn't! If you can reproduce you should file a bug.
      - zaarn 9y ago
        It might help to know that I was writing an UEFI application, so basically kernel mode. Otherwise, I've redesigned the affected subsystem so I'm not sure I could reproduce the behaviour
- zaarn 9y ago
  NULL is still a valid memory address, which in this case I had to use. When packing such an address into a mut or const within a Option<>, a NULL will be treated like a None when you write, essentiall, Some(NULL).