4 ms·

I don't get what you or the comment you're responding to are wishing for. Do you want compilers to stop adding optimizations while staying within the bounds de

by hnjst 5y ago

I don't get what you or the comment you're responding to are wishing for. Do you want compilers to stop adding optimizations while staying within the bounds defined by the spec? That they somehow guess that a given piece of code that may trigger UB is too important for them to optimize it based on the assumption that the developer knew what she was doing and ensured that it wouldn't? The case of a compiler update breaking the test sounds like desirable to me. It pinpoints a critical piece of code that was relying on a specific implementation's behavior that is not specified. This could have been triggered by a compiler or architecture change. If this is something that is a hassle to fix immediately, you can temporarily downgrade to the version of the compiler used earlier or disable some optimizations. I fail to see why one would consider a compiler evolving while conforming to language specification defective or malicious (however, with that definition I fear that finding one that isn't may indeed be difficult).

rectang 5y ago
I want default behavior which does not surprise me. I have come to understand that this probably means I want a different language, because the C spec essentially requires compiler authors to make optimizations which introduce surprising semantics in order to compete on performance with other languages. It would be fine if I could opt into new semantics — something like Rust's "editions" would resolve my objections about these compiler optimizations. But that doesn't seem to be on offer in the C ecosystem.
- pjmlp 5y ago
  Only moving away to other languages will do it. C culture and to certain extent Objective-C and C++ ones are tainted by microptimizaitons while typing, where the compilers are the worst examples. Unfortunely UNIX and C go together, so those that want to keep UNIX like platforms around bettter fix C somehow.
  - Gibbon1 5y ago
    I think that's unfair. The taint is 100% on the C++ side of things. Hopefully the newer compiled languages will kill C++.
    - pjmlp 5y ago
      Nope, the tait lies 100% on the copy-paste compatibilty with a C subset.
      - Gibbon1 5y ago
        All you've done here is show that with C the concept of the l-user is still around.
  - rectang 5y ago
    That sucks. I can imagine next generation operating systems improving on Unix technically (standing on the shoulders of giants, yo), but establishing standards a la POSIX will be extremely difficult. It's hard to fight against the interest of platform vendors to lock their users in.
    - pjmlp 5y ago
      Microsoft fought for several years against C, trying to migrate everyone to C++ as the future of Windows systems programming. Yet Azure Sphere, despite its security message, uses C only SDK. Meanwhile Visual Studio now supports C11 and C17. Market pressure, their customers weren't willing to buy into it, and the new Microsoft also wants all those POSIX FOSS packages written in C running on Windows.
a1369209993 5y ago
> I don't get what you or the comment you're responding to are wishing for. Quoting from another of my comments: > > [What are you objecting to?] > Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. That is what the problem is. Undefined behaviour is a licence to implement operations without regard for unusual corner cases, not to infer the absence of said corner cases from those operations and then apply that 'knowledge' elsewhere. > I fail to see why one would consider a compiler evolving while conforming to language specification defective or malicious It's https://en.wikipedia.org/wiki/Malicious_compliance https://en.wikipedia.org/wiki/Malicious_compliance in near-textbook form.
- hnjst 5y ago
  > Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. I'm not completely sure I understand that correctly, but do you mean that statements that are constant unless considering a possible (and "credible"?) implementation of UB shouldn't be fair-game for the compiler to optimize out? EDIT: I think I see a more tricky case that may be one of those you're referring to. Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. I can relate with that but I suspect that it would prevent many classes of branch pruning. I get what you suggest while describing malicious compliance but I can imagine that it could be a false impression resulting from trade-offs that favor optimization opportunities to "out-of-spec but canonical/natural" implementations.
  - a1369209993 5y ago
    > Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to: if(!p) abort(); use(*p); it may do so (undefined behaviour!), but if it chooses not to do so, it may not later pretend that it did, and remove a explict `if(!p)` that the programmer wrote. Given: use(*p); if(!p) return NOPE; this is fine: if(!p) abort(); use(*p); //if(!p) return NOPE; // unreachable because of if, not because of use but not: use(*p); //if(!p) return NOPE; // CVE-20XX-XXXXX The implementation can optimize based on information (like "p is not null") that is actually true (even if that's because it made it true), but not based on information it assumed was true on the basis that it counterfactually could have made it true (but didn't). > it would prevent many classes of branch pruning. Yes, that's the general idea.
thaumasiotes 5y ago
> I fail to see why one would consider a compiler evolving while conforming to language specification defective or malicious Conforming to the spec is not a virtue. We want the compiler to be reasonable, regardless of whether the spec is. When the spec is malicious, conforming to the spec is malicious behavior. For example, the Java spec says that the << operator (bit shift left) will accept any right operand, but performs a modulo-32 operation on the right operand before doing the shift. So `a << 4` is `a` shifted 4 places left, `a << 20` is `a` shifted 20 places left, and `a << 36` is `a` shifted 4 places left again. This is absurd, and I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31. This behavior is documented, but that doesn't make things better, it makes them worse. But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.

by hnjst 5y ago

rectang 5y ago

I want default behavior which does not surprise me. I have come to understand that this probably means I want a different language, because the C spec essentially requires compiler authors to make optimizations which introduce surprising semantics in order to compete on performance with other languages. It would be fine if I could opt into new semantics — something like Rust's "editions" would resolve my objections about these compiler optimizations. But that doesn't seem to be on offer in the C ecosystem.

pjmlp 5y ago
Only moving away to other languages will do it. C culture and to certain extent Objective-C and C++ ones are tainted by microptimizaitons while typing, where the compilers are the worst examples. Unfortunely UNIX and C go together, so those that want to keep UNIX like platforms around bettter fix C somehow.
- Gibbon1 5y ago
  I think that's unfair. The taint is 100% on the C++ side of things. Hopefully the newer compiled languages will kill C++.
  - pjmlp 5y ago
    Nope, the tait lies 100% on the copy-paste compatibilty with a C subset.
    - Gibbon1 5y ago
      All you've done here is show that with C the concept of the l-user is still around.
- rectang 5y ago
  That sucks. I can imagine next generation operating systems improving on Unix technically (standing on the shoulders of giants, yo), but establishing standards a la POSIX will be extremely difficult. It's hard to fight against the interest of platform vendors to lock their users in.
  - pjmlp 5y ago
    Microsoft fought for several years against C, trying to migrate everyone to C++ as the future of Windows systems programming. Yet Azure Sphere, despite its security message, uses C only SDK. Meanwhile Visual Studio now supports C11 and C17. Market pressure, their customers weren't willing to buy into it, and the new Microsoft also wants all those POSIX FOSS packages written in C running on Windows.

a1369209993 5y ago

> I don't get what you or the comment you're responding to are wishing for. Quoting from another of my comments: > > [What are you objecting to?] > Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. That is what the problem is. Undefined behaviour is a licence to implement operations without regard for unusual corner cases, not to infer the absence of said corner cases from those operations and then apply that 'knowledge' elsewhere. > I fail to see why one would consider a compiler evolving while conforming to language specification defective or malicious It's https://en.wikipedia.org/wiki/Malicious_compliance https://en.wikipedia.org/wiki/Malicious_compliance in near-textbook form.

hnjst 5y ago
> Inferring any propositional statement about the program (eg "this pointer is not null") from the fact that its negation would imply undefined behaviour. I'm not completely sure I understand that correctly, but do you mean that statements that are constant unless considering a possible (and "credible"?) implementation of UB shouldn't be fair-game for the compiler to optimize out? EDIT: I think I see a more tricky case that may be one of those you're referring to. Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. I can relate with that but I suspect that it would prevent many classes of branch pruning. I get what you suggest while describing malicious compliance but I can imagine that it could be a false impression resulting from trade-offs that favor optimization opportunities to "out-of-spec but canonical/natural" implementations.
- a1369209993 5y ago
  > Dereferencing a pointer further in the code shouldn't be a valid justification for optimizing out previous tests of it being null. Not further. Anywhere. If the implementation wishes to rewrite pointer dereferences from `use(*p)` to: if(!p) abort(); use(*p); it may do so (undefined behaviour!), but if it chooses not to do so, it may not later pretend that it did, and remove a explict `if(!p)` that the programmer wrote. Given: use(*p); if(!p) return NOPE; this is fine: if(!p) abort(); use(*p); //if(!p) return NOPE; // unreachable because of if, not because of use but not: use(*p); //if(!p) return NOPE; // CVE-20XX-XXXXX The implementation can optimize based on information (like "p is not null") that is actually true (even if that's because it made it true), but not based on information it assumed was true on the basis that it counterfactually could have made it true (but didn't). > it would prevent many classes of branch pruning. Yes, that's the general idea.

thaumasiotes 5y ago

> I fail to see why one would consider a compiler evolving while conforming to language specification defective or malicious Conforming to the spec is not a virtue. We want the compiler to be reasonable, regardless of whether the spec is. When the spec is malicious, conforming to the spec is malicious behavior. For example, the Java spec says that the << operator (bit shift left) will accept any right operand, but performs a modulo-32 operation on the right operand before doing the shift. So `a << 4` is `a` shifted 4 places left, `a << 20` is `a` shifted 20 places left, and `a << 36` is `a` shifted 4 places left again. This is absurd, and I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31. This behavior is documented, but that doesn't make things better, it makes them worse. But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.