3 ms·

The difference is that Cpp2's in/out references are actually useful. With them, it would be feasible to completely ban uninitialized variables. BTW, P2723[1] t

The difference is that Cpp2's in/out references are actually useful. With them, it would be feasible to completely ban uninitialized variables. BTW, P2723[1] tries to solve the same problem by zero-initializing everything by default. I'm not a fan of it. It's less elegant, it incurs potential performance cost and zero isn't always the right default. [1] - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p27...

dataflow 4y ago
I don't understand that proposal. Compilers can already add (and already have added) a flag to auto-initialize variables (-ftrivial-auto-var-init?) if they want to... so why isn't that the end of the story? It's one thing to say "all variables must be auto-initialized" (which can doesn't need this proposal, as compilers can already do it), and I can understand that. But it's another thing entirely to say "programs should be able to depend on the auto-initialized value", which is what this proposal seems to be actually asking for. That's asking for an explicit language feature to be made implicit, and it's orthogonal to the security issue it's claiming to address. Why?
- pjmlp 4y ago
  Because it isn't part of the language official semantics, and is compiler specific.
  - josefx 4y ago
    It seems to be at least supported by gcc and clang, I am not sure about Microsofts compiler, however I thought clang could produce compatible binaries? This seems to be a non issue?
    - pjmlp 4y ago
      There are more than 3 compilers out there....
      - JonChesterfield 4y ago
        For C++? Approximately following the standard evolving? Can't think of a fourth still surviving
        pjmlp 4y ago
        Intel, PGI, .... As for the rest, what matters is what the OS vendors puts on the SDK for the CPU one needs to write an application for, and there is a world out there besides mainstream desktop OSes and mobile phones.
  - dataflow 4y ago
    The spec could just say "compilers must provide an external mechanism to initialize all variables automatically" without actually letting all programs depend on this feature being enabled. If security is the problem, letting people control this at the compiler level seems like the solution. Not forcing a semantic change on all program authors.

dataflow 4y ago

I don't understand that proposal. Compilers can already add (and already have added) a flag to auto-initialize variables (-ftrivial-auto-var-init?) if they want to... so why isn't that the end of the story? It's one thing to say "all variables must be auto-initialized" (which can doesn't need this proposal, as compilers can already do it), and I can understand that. But it's another thing entirely to say "programs should be able to depend on the auto-initialized value", which is what this proposal seems to be actually asking for. That's asking for an explicit language feature to be made implicit, and it's orthogonal to the security issue it's claiming to address. Why?

pjmlp 4y ago
Because it isn't part of the language official semantics, and is compiler specific.
- josefx 4y ago
  It seems to be at least supported by gcc and clang, I am not sure about Microsofts compiler, however I thought clang could produce compatible binaries? This seems to be a non issue?
  - pjmlp 4y ago
    There are more than 3 compilers out there....
    - JonChesterfield 4y ago
      For C++? Approximately following the standard evolving? Can't think of a fourth still surviving
      - pjmlp 4y ago
        Intel, PGI, .... As for the rest, what matters is what the OS vendors puts on the SDK for the CPU one needs to write an application for, and there is a world out there besides mainstream desktop OSes and mobile phones.
- dataflow 4y ago
  The spec could just say "compilers must provide an external mechanism to initialize all variables automatically" without actually letting all programs depend on this feature being enabled. If security is the problem, letting people control this at the compiler level seems like the solution. Not forcing a semantic change on all program authors.