4 ms·

>You are responsible for testing the code you write, not the one that actually runs That's a bizarre claim. The source code isn't the product, and the product

>You are responsible for testing the code you write, not the one that actually runs That's a bizarre claim. The source code isn't the product, and the product is what has to work. If a compiler or OS bug causes your product to function incorrectly, it's still your problem. The solution is to either work around the bug or get the bug fixed, not just say "I didn't write the bug, so deal with it."

selcuka 1y ago
You are a better developer than me, then. I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". If you are suspicious about gcc, you should submit your patches to gcc, not vendor them in your own repo.
- thfuran 1y ago
  >I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? Are you asking whether I write integration tests? Yes, I do. And at work there's a whole lot of acceptance testing too. >There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". They're not proposing writing unit tests for gcc, only actually testing what gcc produces from their source. You know, by executing it like tests tend to do. Testing only the first party source would mean relying entirely on static source code analysis instead.
  - selcuka 1y ago
    > Are you asking whether I write integration tests? Yes, I do. Exactly. You don't need unit tests for the binary output. You want to test whether the executable behaves as expected. Therefore "rust adds extra conditional branches that are never entered, and we can't test those branches" argument is not valid.

selcuka 1y ago

You are a better developer than me, then. I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". If you are suspicious about gcc, you should submit your patches to gcc, not vendor them in your own repo.

thfuran 1y ago
>I take it you have tests in your product repos that test your compiler behaviour, including optimisations that you enable while building binaries, and all third party dependencies you use. Is that accurate? Are you asking whether I write integration tests? Yes, I do. And at work there's a whole lot of acceptance testing too. >There is a difference between "gcc 4.8 is buggy, let's not use it" and "let's write unit tests for gcc". They're not proposing writing unit tests for gcc, only actually testing what gcc produces from their source. You know, by executing it like tests tend to do. Testing only the first party source would mean relying entirely on static source code analysis instead.
- selcuka 1y ago
  > Are you asking whether I write integration tests? Yes, I do. Exactly. You don't need unit tests for the binary output. You want to test whether the executable behaves as expected. Therefore "rust adds extra conditional branches that are never entered, and we can't test those branches" argument is not valid.