4 ms·

Because you'll spend a lot of time chasing down bugs that are actually issues in the compiler. Unless you're trying to vet the compiler itself, this won't impro

Because you'll spend a lot of time chasing down bugs that are actually issues in the compiler. Unless you're trying to vet the compiler itself, this won't improve your software but cost you a lot of effort.

saagarjha 6y ago
If you’re SQLite, you generally do care about popular compilers converting your code into something wrong because you care about your code doing something wrong in general. If there was a bug in Intel processors that made SQLite fault randomly during tests, I’m sure they’d be interested in that too.
- Nitramp 6y ago
  Yes. Two things though: 1. Hopefully none of your users run an unreleased clang from head, so you're not using anything a user will run into. 2. Consider if it is it worth the effort to validate every commit pushed to head, or whether you'd get more out of your investment if you only tested releases that received some more vetting (e.g. nightlies).
  - saagarjha 6y ago
    I don’t think SQLite is literally vetting every commit. (Although kudos to them if they are!)
  - progval 6y ago
    > 1. Hopefully none of your users run an unreleased clang from head, so you're not using anything a user will run into. Yes, but clang eventually gets released. You want to catch bugs in clang and get them fixed before that release happens.
    - jfkebwjsbx 6y ago
      Yes, but Clang is many months away from a release. It is not the same as playing with a release candidate.
      - pas 6y ago
        It's an automated fuzzer, it caught a bug very early, but the report got sent to SQLite instead of Clang. Probably because OSFuzz doesn't handle this distinction. (Though it might should. Or maybe usually new compiler versions catch problems in old code a lot more frequently than it catches compiler bugs. Dunno.)
      - deleted 6y ago
        [deleted]
  - deleted 6y ago
    [deleted]
Carpetsmoker 6y ago
On the other hand, you might catch either program or compiler bugs before it's too late and it has shipped to production. I think this would improve the software, and I'm also not so sure a lot of time is spent on this, and it wasn't even something caught by SQLite devs, but rather an external project which SQLite decided to work around for now.

saagarjha 6y ago

If you’re SQLite, you generally do care about popular compilers converting your code into something wrong because you care about your code doing something wrong in general. If there was a bug in Intel processors that made SQLite fault randomly during tests, I’m sure they’d be interested in that too.

Nitramp 6y ago
Yes. Two things though: 1. Hopefully none of your users run an unreleased clang from head, so you're not using anything a user will run into. 2. Consider if it is it worth the effort to validate every commit pushed to head, or whether you'd get more out of your investment if you only tested releases that received some more vetting (e.g. nightlies).
- saagarjha 6y ago
  I don’t think SQLite is literally vetting every commit. (Although kudos to them if they are!)
- progval 6y ago
  > 1. Hopefully none of your users run an unreleased clang from head, so you're not using anything a user will run into. Yes, but clang eventually gets released. You want to catch bugs in clang and get them fixed before that release happens.
  - jfkebwjsbx 6y ago
    Yes, but Clang is many months away from a release. It is not the same as playing with a release candidate.
    - pas 6y ago
      It's an automated fuzzer, it caught a bug very early, but the report got sent to SQLite instead of Clang. Probably because OSFuzz doesn't handle this distinction. (Though it might should. Or maybe usually new compiler versions catch problems in old code a lot more frequently than it catches compiler bugs. Dunno.)
    - deleted 6y ago
      [deleted]
- deleted 6y ago
  [deleted]

Carpetsmoker 6y ago

On the other hand, you might catch either program or compiler bugs before it's too late and it has shipped to production. I think this would improve the software, and I'm also not so sure a lot of time is spent on this, and it wasn't even something caught by SQLite devs, but rather an external project which SQLite decided to work around for now.