4 ms·

> This makes it difficult to read the rest of the article. Really? All compiler authors, as a blanket statement, act in bad faith? Whenever possible? When I sa

> This makes it difficult to read the rest of the article. Really? All compiler authors, as a blanket statement, act in bad faith? Whenever possible? When I saw the link was to DJB’s site, I figured the post would contain a vitriolic and hyperbolic rant. It’s pretty on-brand for him (although, to be fair, he’s usually right.)

josephcsible 2y ago
> (although, to be fair, he’s usually right.) This is worth emphasizing. I actually can't think of any articles of his other than this one that miss the mark.
- jonhohle 2y ago
  I’m not sure this one is wrong, especially if you’ve been bitten by underdocumented compiler or framework changes that modify behavior of previously working code. For example, I have a small utility app built against SwiftUI for macOS 13. Compiling on macOS 14 while still linking against frameworks for 13 results in broken UI interaction in a particular critical use case. This was a deliberate change made to migrate devs away from a particular API, but it fails silently at compile time and runtime. Moving the code back to a macOS 13 machine would produce the correct result. As a dev, I can no longer trust that linking against specific library version will produce the same result and now need to think of some tuple of compile host and library version At one point should working code be considered correct and complete when compiler writers change code generation that doesn’t depend on UB? I’m sure it’s worse for JITed languages where constant time operations work in test and for the first few hundred iterations and then are “optimized” into variable time branching instructions on a production host somewhere.
  - saagarjha 2y ago
    No, he’s wrong. What you’re talking about is completely different than what you are: your code doesn’t work because Apple changes the behavior of their frameworks, which has nothing to do with what compiler you’re using. There’s a different contract there than what a C compiler gives you.
    - jonhohle 2y ago
      It’s not quite that simple in Swift-land. There is a significant overlap between what’s compiler and what’s runtime. I’m supposedly linking against the same libraries, but changing the host platform changes the output binaries. Same code, same linked libraries, different host platform, different codegen. Mine isn’t security critical, but the result is similarly unexpected.
      - KerrAvon 2y ago
        It’s really not the same thing. Your complaint is about Apple’s complex framework API management, not about the compiler optimization/undefined behavior. Swift frameworks sometimes blur the line the way I think you mean by being able to be back-deployed to earlier OS releases through embedding in your binary. Apple’s documentation is poor (and has been since the NeXT takeover in 1997), but, again, that’s not a compiler issue as such.
- tptacek 2y ago
  The "debunking NIST's calculation" one was, if I'm remembering this right, refuted by Chris Peikert on the PQC mailing list immediately after it was posted.
UncleMeat 2y ago
I don't think DJB is right here, but I do think he is one of the few "ugh compilers taking advantage of UB" people who is actually serious about it. DJB wants absolute certainty in predicting the compiled code so that he can make significantly stronger guarantees about his programs than almost anybody else needs. The bad news for him is that the bulk of clang users aren't writing core cryptographic primitives and really DJB just needs a different language and compiler stack for his specific goals.
- g-b-r 2y ago
  The bad news for us is that plenty of cryptographic (or otherwise critical) code is already written in C or C++, and when compiler writers play with their optimizations, they cause real-world problems to a good portion of the population

josephcsible 2y ago

> (although, to be fair, he’s usually right.) This is worth emphasizing. I actually can't think of any articles of his other than this one that miss the mark.

jonhohle 2y ago
I’m not sure this one is wrong, especially if you’ve been bitten by underdocumented compiler or framework changes that modify behavior of previously working code. For example, I have a small utility app built against SwiftUI for macOS 13. Compiling on macOS 14 while still linking against frameworks for 13 results in broken UI interaction in a particular critical use case. This was a deliberate change made to migrate devs away from a particular API, but it fails silently at compile time and runtime. Moving the code back to a macOS 13 machine would produce the correct result. As a dev, I can no longer trust that linking against specific library version will produce the same result and now need to think of some tuple of compile host and library version At one point should working code be considered correct and complete when compiler writers change code generation that doesn’t depend on UB? I’m sure it’s worse for JITed languages where constant time operations work in test and for the first few hundred iterations and then are “optimized” into variable time branching instructions on a production host somewhere.
- saagarjha 2y ago
  No, he’s wrong. What you’re talking about is completely different than what you are: your code doesn’t work because Apple changes the behavior of their frameworks, which has nothing to do with what compiler you’re using. There’s a different contract there than what a C compiler gives you.
  - jonhohle 2y ago
    It’s not quite that simple in Swift-land. There is a significant overlap between what’s compiler and what’s runtime. I’m supposedly linking against the same libraries, but changing the host platform changes the output binaries. Same code, same linked libraries, different host platform, different codegen. Mine isn’t security critical, but the result is similarly unexpected.
    - KerrAvon 2y ago
      It’s really not the same thing. Your complaint is about Apple’s complex framework API management, not about the compiler optimization/undefined behavior. Swift frameworks sometimes blur the line the way I think you mean by being able to be back-deployed to earlier OS releases through embedding in your binary. Apple’s documentation is poor (and has been since the NeXT takeover in 1997), but, again, that’s not a compiler issue as such.
tptacek 2y ago
The "debunking NIST's calculation" one was, if I'm remembering this right, refuted by Chris Peikert on the PQC mailing list immediately after it was posted.

UncleMeat 2y ago

I don't think DJB is right here, but I do think he is one of the few "ugh compilers taking advantage of UB" people who is actually serious about it. DJB wants absolute certainty in predicting the compiled code so that he can make significantly stronger guarantees about his programs than almost anybody else needs. The bad news for him is that the bulk of clang users aren't writing core cryptographic primitives and really DJB just needs a different language and compiler stack for his specific goals.

g-b-r 2y ago
The bad news for us is that plenty of cryptographic (or otherwise critical) code is already written in C or C++, and when compiler writers play with their optimizations, they cause real-world problems to a good portion of the population