6 ms·

Not really, at least, not given the current info. Does anyone have a link to the reported clang bug? For example, it might well be that the function that clan

Not really, at least, not given the current info. Does anyone have a link to the reported clang bug? For example, it might well be that the function that clang believes does not modify pmem->flags "promises" that it does not modify the value. In which case it might be an SQLite bug, that clang just did not happen to "correctly optimize" before. This can happen, e.g., if you mark your function with __attribute__((const)), for example, which promises that your function does not access memory via arguments that have pointers. It then becomes trivial for clang to make the transformation above. The bug wouldn't even need to be on the function definition, it might just be on the declaration, or on a declaration somewhere, in which case you have an ODR violation as well. All that seems very unlikely since it appears to be clear that the function does modify memory, but still, I'd just wait for the clang bug to be filled with a reproducer, and the issue to be tracked down. It does strongly hint at a bug in clang, but from the linked page, I at least cannot conclude that yet.

mrjin 6y ago
Please, the code is there, read it rather than make assumptions this might happen or that might happen. It's just plain C code all the way there was no fancy "const" stuff anywhere involved in this case. Just as claimed, CLang tried to do some optimization and unfortunately it was FUBAR.
- deleted 6y ago
  [deleted]
- fluffything 6y ago
  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
matheusalmeida 6y ago
Clang reported bug: http://lists.llvm.org/pipermail/llvm-bugs/2020-June/084028.html http://lists.llvm.org/pipermail/llvm-bugs/2020-June/084028.h... Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=46194 https://bugs.llvm.org/show_bug.cgi?id=46194
- fluffything 6y ago
  Appears to already be fixed, thanks for the link!

mrjin 6y ago

Please, the code is there, read it rather than make assumptions this might happen or that might happen. It's just plain C code all the way there was no fancy "const" stuff anywhere involved in this case. Just as claimed, CLang tried to do some optimization and unfortunately it was FUBAR.

deleted 6y ago
[deleted]
fluffything 6y ago
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

matheusalmeida 6y ago

Clang reported bug: http://lists.llvm.org/pipermail/llvm-bugs/2020-June/084028.html http://lists.llvm.org/pipermail/llvm-bugs/2020-June/084028.h... Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=46194 https://bugs.llvm.org/show_bug.cgi?id=46194

fluffything 6y ago
Appears to already be fixed, thanks for the link!