3 ms·

This is why we test our code, or build in runtime checks, before releasing it.

by nomel 5y ago

TillE 5y ago
Absolutely, it makes far more sense to do some basic sanity checks instead of writing painfully awkward code out of fear of a hypothetical. The standard may be flexible, but the behavior of a given compiler on a given platform will be consistent and very unlikely to change in the foreseeable future.
- ncmncm 5y ago
  Wrong.
  - TillE 5y ago
    Perfectionist nerds love to obsess over a million scenarios which only exist in their head, or in obscure edge cases. This is not productive. Perfectly portable, future-proof, CPU-bug-proof code simply does not exist. The only thing to be aware of here is that you shouldn't be trying to transfer data from one platform to another, loading it directly into memory, which is an insane thing to do in any case.
    - ncmncm 5y ago
      You may ignore field experience freely if you are insulated from all consequences.
ncmncm 5y ago
You really are failing to get this! Testing formally-correct code can only ever find bugs in the exact compiler release and physical CPU chip you run the test on. The bugs cited show up in various compiler releases and various chip steppings. Unless your code will only ever run on that exact machine, you have not tested it.
- nomel 5y ago
  > Unless your code will only ever run on that exact machine, you have not tested it. I don't understand this sentence. That is the purpose of the runtime check, to make sure the code generated by a buggy compiler, on a specific architecture, doesn't try to run. Bug reports can then be filed, as they should be. If you're writing a Linux kernel module (known compiler) for a known architecture, which is where this is often used, then you have a known environment, so there's little risk, except the rare compiler bug, which is a risk that extends far beyond packed structs. This is something that I've used, and I've seen used, often in the hardware world. I'm having difficulty sympathizing with all the fear in this comment section. Don't use it if its use can't be made rational, for you. But please don't tell me that I'm failing to get something that I am familiar with.
  - ncmncm 5y ago
    Still not getting it.
    - nomel 5y ago
      I certainly don't understand what you're trying to say, and replying with four words definitely won't help me. Perhaps there's some confusion of what a runtime check is. A runtime check is executed at runtime, which means that it will be executed after compilation with a specific compiler, on a specific architecture, in the end user system. The runtime check verifies correct struct operations at runtime, as part of the initialization, and aborts the driver load, with a nice system message, if improper packed struct behavior (among other things) is seen. This covers your concern here: > Unless your code will only ever run on that exact machine, you have not tested it. It literally is tested on every machine, when the driver is loaded. This runtime check handles the cases where a customer might try to run it on some new hardware/toolchain that we don't officially support. The official supported cases only have risk of new compiler bugs, since we only support certain architectures. Hypothetical compiler bugs are a problem for all software, and shouldn't be used to drive software design, beyond making sure there is good testing, which has nothing to do with compilers. Maybe I'm missing something. edit: ncmncm, I can't reply to you, but since I have code that does what you say is impossible, and since my comment already responds to what you wrote, I would suggest reading all of my comments, fully, a second time.

This is why we test our code, or build in runtime checks, before releasing it.

by nomel 5y ago

This is why we test our code, or build in runtime checks, before releasing it.

Absolutely, it makes far more sense to do some basic sanity checks instead of writing painfully awkward code out of fear of a hypothetical. The standard may be flexible, but the behavior of a given compiler on a given platform will be consistent and very unlikely to change in the foreseeable future.

ncmncm 5y ago
Wrong.
- TillE 5y ago
  Perfectionist nerds love to obsess over a million scenarios which only exist in their head, or in obscure edge cases. This is not productive. Perfectly portable, future-proof, CPU-bug-proof code simply does not exist. The only thing to be aware of here is that you shouldn't be trying to transfer data from one platform to another, loading it directly into memory, which is an insane thing to do in any case.
  - ncmncm 5y ago
    You may ignore field experience freely if you are insulated from all consequences.

ncmncm 5y ago

You really are failing to get this! Testing formally-correct code can only ever find bugs in the exact compiler release and physical CPU chip you run the test on. The bugs cited show up in various compiler releases and various chip steppings. Unless your code will only ever run on that exact machine, you have not tested it.

nomel 5y ago
> Unless your code will only ever run on that exact machine, you have not tested it. I don't understand this sentence. That is the purpose of the runtime check, to make sure the code generated by a buggy compiler, on a specific architecture, doesn't try to run. Bug reports can then be filed, as they should be. If you're writing a Linux kernel module (known compiler) for a known architecture, which is where this is often used, then you have a known environment, so there's little risk, except the rare compiler bug, which is a risk that extends far beyond packed structs. This is something that I've used, and I've seen used, often in the hardware world. I'm having difficulty sympathizing with all the fear in this comment section. Don't use it if its use can't be made rational, for you. But please don't tell me that I'm failing to get something that I am familiar with.
- ncmncm 5y ago
  Still not getting it.
  - nomel 5y ago
    I certainly don't understand what you're trying to say, and replying with four words definitely won't help me. Perhaps there's some confusion of what a runtime check is. A runtime check is executed at runtime, which means that it will be executed after compilation with a specific compiler, on a specific architecture, in the end user system. The runtime check verifies correct struct operations at runtime, as part of the initialization, and aborts the driver load, with a nice system message, if improper packed struct behavior (among other things) is seen. This covers your concern here: > Unless your code will only ever run on that exact machine, you have not tested it. It literally is tested on every machine, when the driver is loaded. This runtime check handles the cases where a customer might try to run it on some new hardware/toolchain that we don't officially support. The official supported cases only have risk of new compiler bugs, since we only support certain architectures. Hypothetical compiler bugs are a problem for all software, and shouldn't be used to drive software design, beyond making sure there is good testing, which has nothing to do with compilers. Maybe I'm missing something. edit: ncmncm, I can't reply to you, but since I have code that does what you say is impossible, and since my comment already responds to what you wrote, I would suggest reading all of my comments, fully, a second time.