3 ms·

Sorry, but no. As a compiler writer, the burden of proof that this is a bug isn't on me, its on you. If you believe this is a bug in clang, open up a bug with a

Sorry, but no. As a compiler writer, the burden of proof that this is a bug isn't on me, its on you. If you believe this is a bug in clang, open up a bug with a reproducer, and get somebody to analyze it and confirm it. SQLite isn't a tiny project, so doing that should be quite easy. I have better things to do than reading the whole SQLite code base like, for example, fixing the bugs of the people that actually bothered to fill in a bug report. Until this bug is confirmed, it can be anything, and unfortunately, bugs reported for C and C++ projects are quite often not bugs in the compiler, but UB in user code. The fact that you think that just by looking at a single function signature one can deduce where this could be UB related to const depicts the problem. UB is unfortunately not that simple, and I can think of a couple of ways of const-related UB in which the declaration "looked fine".

RcouF1uZ4gsC 6y ago
> As a compiler writer, the burden of proof that this is a bug isn't on me, its on you. Normally true, but not for SQLite. SQLite is probably the most thoroughly tested and correctness conscious piece of software anywhere in open source. I think with SQLite, the burden is on the compiler writer.
- the_why_of_y 6y ago
  Nevertheless OSSFuzz found legitimate UB bugs in SQLite before. https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Proj%3Dsqlite3+Type%3DBug-Security+status%3ANew%2CAccepted%2CFixed%2CVerified&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Pro...
- fluffything 6y ago
  > SQLite is probably the most thoroughly tested and correctness conscious piece of software anywhere in open source. Given the amounts of bugs that are both filled and fixed on a daily basis, reality does not seem to reflect this claim. If you expect compiler writers to go and explore your open source project of choice in a blind hunt for compiler bugs that they can fix, I hope you sit down while you wait and do not really need these kinds of bugs actually fixed.
btilly 6y ago
As a developer, this attitude on the part of C compiler writers is a reason to avoid C and C++. The actual semantics of the language are effectively impossible for a non-expert to tell from the code as written and operating. And what you don't know can hurt you. That's like juggling caltrops with bare hands - you're guaranteed to get hurt.
- icedchai 6y ago
  This got worse over the past 10 - 15 years, as people went optimization crazy.
- Gibbon1 6y ago
  I think the attitude of compiler writers is a good reason to fix the spec so they can't keep ratfucking developers trying to get work done.
- fluffything 6y ago
  > As a developer, this attitude on the part of C compiler writers is a reason to avoid C and C++. Which attitude? The one that requests users to fill a bug report if they think there is an error in our compiler ? Please let us all know which software you write and ship, and how you inspect all inputs that your users pass it in the search for bugs, instead of requiring users to fill a bug report if they think they encounter a bug. Or maybe you are talking about the attitude of not assuming that all users know the C standard to the letter and never write code that has bugs ? I suppose that for all the C and C++ code that you write, when the binary doesn't work as expected, you start by looking for bugs in compilers instead of proofing your own code right? Because it is almost impossible to write subtly buggy code in C and C++ right?
  - btilly 6y ago
    Which attitude? The attitude that undefined behavior is seen as an opportunity for optimization, and backwards compatibility with your installed base is not particularly important. Not even if you know that the change breaks code in the wild which was intended for security checks. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 for discussion around one such change. I will elide the specific self-congratulatory attitudes that you claim to have, and your not so subtle insults to myself. With one exception. Or maybe you are talking about the attitude of not assuming that all users know the C standard to the letter and never write code that has bugs ? This is exactly the reverse of the attitude that I've observed. Including in yourself 2 posts up when you described how hard it can be to decide whether something is undefined behavior, but if it is undefined behavior then it isn't a compiler bug. Which, as a developer, tells me that I definitely am not able to decide whether the code will do anything like what appears to be written, or I will get unexpected nasal demons, in some unrelated section of code.

RcouF1uZ4gsC 6y ago

> As a compiler writer, the burden of proof that this is a bug isn't on me, its on you. Normally true, but not for SQLite. SQLite is probably the most thoroughly tested and correctness conscious piece of software anywhere in open source. I think with SQLite, the burden is on the compiler writer.

the_why_of_y 6y ago
Nevertheless OSSFuzz found legitimate UB bugs in SQLite before. https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Proj%3Dsqlite3+Type%3DBug-Security+status%3ANew%2CAccepted%2CFixed%2CVerified&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Pro...
fluffything 6y ago
> SQLite is probably the most thoroughly tested and correctness conscious piece of software anywhere in open source. Given the amounts of bugs that are both filled and fixed on a daily basis, reality does not seem to reflect this claim. If you expect compiler writers to go and explore your open source project of choice in a blind hunt for compiler bugs that they can fix, I hope you sit down while you wait and do not really need these kinds of bugs actually fixed.

btilly 6y ago

As a developer, this attitude on the part of C compiler writers is a reason to avoid C and C++. The actual semantics of the language are effectively impossible for a non-expert to tell from the code as written and operating. And what you don't know can hurt you. That's like juggling caltrops with bare hands - you're guaranteed to get hurt.

icedchai 6y ago
This got worse over the past 10 - 15 years, as people went optimization crazy.
Gibbon1 6y ago
I think the attitude of compiler writers is a good reason to fix the spec so they can't keep ratfucking developers trying to get work done.
fluffything 6y ago
> As a developer, this attitude on the part of C compiler writers is a reason to avoid C and C++. Which attitude? The one that requests users to fill a bug report if they think there is an error in our compiler ? Please let us all know which software you write and ship, and how you inspect all inputs that your users pass it in the search for bugs, instead of requiring users to fill a bug report if they think they encounter a bug. Or maybe you are talking about the attitude of not assuming that all users know the C standard to the letter and never write code that has bugs ? I suppose that for all the C and C++ code that you write, when the binary doesn't work as expected, you start by looking for bugs in compilers instead of proofing your own code right? Because it is almost impossible to write subtly buggy code in C and C++ right?
- btilly 6y ago
  Which attitude? The attitude that undefined behavior is seen as an opportunity for optimization, and backwards compatibility with your installed base is not particularly important. Not even if you know that the change breaks code in the wild which was intended for security checks. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 for discussion around one such change. I will elide the specific self-congratulatory attitudes that you claim to have, and your not so subtle insults to myself. With one exception. Or maybe you are talking about the attitude of not assuming that all users know the C standard to the letter and never write code that has bugs ? This is exactly the reverse of the attitude that I've observed. Including in yourself 2 posts up when you described how hard it can be to decide whether something is undefined behavior, but if it is undefined behavior then it isn't a compiler bug. Which, as a developer, tells me that I definitely am not able to decide whether the code will do anything like what appears to be written, or I will get unexpected nasal demons, in some unrelated section of code.