4 ms·

Richard Hipp (creator of SQLite) had this to say about Rust and SQLite in the comments: > Rewriting SQLite in Rust, or some other trendy “safe” language, would

Richard Hipp (creator of SQLite) had this to say about Rust and SQLite in the comments: > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in an unexpected or harmful way. We know this, because we have tested the SQLite machine code – every single instruction – using many different compilers, on many different CPU architectures and operating systems and with many different compile-time options. So there is nothing wrong with the sqlite3.so or sqlite3.dylib or winsqlite3.dll library that is happily running on your computer. Those files contain no source code, and hence no UB. The point of Prof. Regehr’s post (as I understand it) is the the C programming language as evolved to contain such byzantine rules that even experts find it difficult to write complex programs that do not contain UB. The rules of rust are less byzantine (so far – give it time :-)) and so in theory it should be easier to write programs in rust that do not contain UB. That’s all well and good. But it does not relieve the programmer of the responsibility of testing the machine code to make sure it really does work as intended. The rust compiler contains bugs. (I don’t know what they are but I feel sure there must be some.) Some well-formed rust programs will generate machine code that behaves differently from what the programmer expected. In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. But whatever you call it, the outcome is the same: the program does not work. And the only way to find these problems is to thoroughly test the actual machine code. And that is where rust falls down. Because it is a newer language, it does not have (afaik) tools like gcov that are so helpful for doing machine-code testing. Nor are there multiple independently-developed rust compilers for diversity testing. Perhaps that situation will change as rust becomes more popular, but that is the situation for now.

pcwalton 8y ago
One problem with this argument is that SQLite is primarily used as a source-level embeddable library. That is, most users of SQLite don't use the official binaries and instead build the source code themselves. So, in practice, the source code, not the official blessed binary, is what matters. When upgrading compilers, developers of apps that embed SQLite don't typically check to ensure that upstream SQLite has tested the new version of their compiler. They just upgrade their compiler and assume that the new version will continue to compile their SQLite source properly. If the new version of the compiler happens to compile programs with undefined behavior differently, then problems can arise.
- SloopJon 8y ago
  Right, and the much vaunted test suite is proprietary, so the typical end user can't reproduce this test of "every single instruction." Not that I'm taking sides here. I'm really interested in both the extensive testing that the SQLite team does, and the analysis that John blogs about.
pjmlp 8y ago
Compiler bugs are supposed to get fixed. In C regarding UB, everything goes every single time the compiler gets upgraded.
- dangerbird2 8y ago
  In many cases, what is considered UB in the C standard is a widely accepted and documented extension in the vast majority of compilers. For example, nonstrict aliases are UB in ISO C, but are defined language extensions in MSVC, GCC, clang, and many other compiler vendors.
  - pjmlp 8y ago
    Now try to maintain a large C codebase stable and safe across such variety of compilers.
ignoramous 8y ago
Previous discussion: https://news.ycombinator.com/item?id=11312918 https://news.ycombinator.com/item?id=11312918 Related: https://news.ycombinator.com/item?id=11337399 https://news.ycombinator.com/item?id=11337399
blub 8y ago
He's not wrong, SQLite is a very well tested piece of software and probably the best that can be done safety-wise in C. Still, as it was pointed out by pcwalton below, and also last time this topic was discussed, there are some use cases where tests done on the entirety machine code do not guarantee that UB will not occur. For one, it's quite likely that an embedded platform's toolchain will not be part of the SQLite test configurations. Secondly, SQLite can be and is compiled into a binary, and this means that all bets are off, especially if LTO is enabled. Thirdly there are products that build on SQLite, such as its own commercial encryption extension and other extensions from third parties. The former probably enjoy the same level of testing, but it's not clear how the latter are tested. The conclusion is that it's humanly impossible to write memory-safe C, even with 100% test coverage, static and dynamic analysis. Something like Frama-C is required, which is virtually unheard of for the majority of open source and commercial software.
Tomte 8y ago
I don't find that comment very impressive, but further down he has commented some more, and I'm fully in agreement there: "The disagreement is not over whether or not UB is a problem, but rather how serious of a problem. Is it like “Emergency patch – update immediately!” or more like “We fixed a compiler warning” or is it something in between."
IshKebab 8y ago
Undefined behaviour is not a compiler bug - it is deliberate. And having undefined behaviour in your C code is definitely not a good thing, even if it is basically unavoidable. The real problem is that the C and C++ standards cop out to UB in too many places, e.g. with things like type aliasing and people reasonably think "weeeell, it may be UB but it works now and I need it so screw it" and then you have a mess of programs relying on de facto non-standard behaviour which is shit. The C people just need to officially define some of the de facto behaviours. Rust doesn't have this problem because it doesn't leave so many basic things undefined.
- akira2501 8y ago
  > The C people just need to officially define some of the de facto behaviours Sure, as soon as the all the different ISA people officially define some of the de facto behaviors. UB isn't in the standard "just because" it's in the standard because there is no apparent underlying standard.
  - cryptonector 8y ago
    Aliasing rules, for example, have nothing to do with ISAs. Neither do pointer comparison rules, and many others besides. The rule about memcmp() with invalid pointers by length zero does have to do with actual systems, but it can still be standardized and the vendors with now-non-compliant memcmp() implementations just have to fix it. This has happened before (e.g., snprintf()), so the ISA thing is a total cop-out.
    - zlynx 8y ago
      Weird ISAs are exactly why you cannot compare pointers. Segmented memory for one. Or imagine an OS and compiler that implemented automatic overlay switching. With that and PAE on 32-bit x86 systems you could have special "far overlay" pointers returned from malloc calls which would map in different 1 GB overlay sections when accessed. Aliasing rules are important in some ISAs too. Like weird DSPs. Imagine a system where 32-bit objects can't even share the same memory space as 8-bit objects. Casting a pointer to a different sized type is completely meaningless there. Of course programming such a weird thing is usually done in assembly, but there are C compilers.
dbaupp 8y ago
> In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. C has both compiler bugs and undefined behaviour. Undefined behaviour is an inherent property of the C standard, while a compiler bug is a property of the implementation (a place where it doesn't match the standard). A valid argument along the same lines might be that the Rust compiler has existed for less time and is used less than C compilers, and therefore is more likely to contain bugs. > Because it is a newer language, it does not have (afaik) tools like gcov that are so helpful for doing machine-code testing. Coverage tools work on Rust, such as kcov. I'm not sure of the state of gcov itself though. > Nor are there multiple independently-developed rust compilers for diversity testing. Isn't diversity testing only necessary/good because there are many C compilers? Using your phrasing, if the code compiles and runs correctly (i.e. every single machine instruction is checked) with the one Rust compiler that exists, then it works. There's definitely many reasons why a language having multiple compilers is good, but I think "diversity testing" is circular logic.

pcwalton 8y ago

One problem with this argument is that SQLite is primarily used as a source-level embeddable library. That is, most users of SQLite don't use the official binaries and instead build the source code themselves. So, in practice, the source code, not the official blessed binary, is what matters. When upgrading compilers, developers of apps that embed SQLite don't typically check to ensure that upstream SQLite has tested the new version of their compiler. They just upgrade their compiler and assume that the new version will continue to compile their SQLite source properly. If the new version of the compiler happens to compile programs with undefined behavior differently, then problems can arise.

SloopJon 8y ago
Right, and the much vaunted test suite is proprietary, so the typical end user can't reproduce this test of "every single instruction." Not that I'm taking sides here. I'm really interested in both the extensive testing that the SQLite team does, and the analysis that John blogs about.

pjmlp 8y ago

Compiler bugs are supposed to get fixed. In C regarding UB, everything goes every single time the compiler gets upgraded.

dangerbird2 8y ago
In many cases, what is considered UB in the C standard is a widely accepted and documented extension in the vast majority of compilers. For example, nonstrict aliases are UB in ISO C, but are defined language extensions in MSVC, GCC, clang, and many other compiler vendors.
- pjmlp 8y ago
  Now try to maintain a large C codebase stable and safe across such variety of compilers.

ignoramous 8y ago

Previous discussion: https://news.ycombinator.com/item?id=11312918 https://news.ycombinator.com/item?id=11312918 Related: https://news.ycombinator.com/item?id=11337399 https://news.ycombinator.com/item?id=11337399

blub 8y ago

He's not wrong, SQLite is a very well tested piece of software and probably the best that can be done safety-wise in C. Still, as it was pointed out by pcwalton below, and also last time this topic was discussed, there are some use cases where tests done on the entirety machine code do not guarantee that UB will not occur. For one, it's quite likely that an embedded platform's toolchain will not be part of the SQLite test configurations. Secondly, SQLite can be and is compiled into a binary, and this means that all bets are off, especially if LTO is enabled. Thirdly there are products that build on SQLite, such as its own commercial encryption extension and other extensions from third parties. The former probably enjoy the same level of testing, but it's not clear how the latter are tested. The conclusion is that it's humanly impossible to write memory-safe C, even with 100% test coverage, static and dynamic analysis. Something like Frama-C is required, which is virtually unheard of for the majority of open source and commercial software.

Tomte 8y ago

I don't find that comment very impressive, but further down he has commented some more, and I'm fully in agreement there: "The disagreement is not over whether or not UB is a problem, but rather how serious of a problem. Is it like “Emergency patch – update immediately!” or more like “We fixed a compiler warning” or is it something in between."

IshKebab 8y ago

Undefined behaviour is not a compiler bug - it is deliberate. And having undefined behaviour in your C code is definitely not a good thing, even if it is basically unavoidable. The real problem is that the C and C++ standards cop out to UB in too many places, e.g. with things like type aliasing and people reasonably think "weeeell, it may be UB but it works now and I need it so screw it" and then you have a mess of programs relying on de facto non-standard behaviour which is shit. The C people just need to officially define some of the de facto behaviours. Rust doesn't have this problem because it doesn't leave so many basic things undefined.

akira2501 8y ago
> The C people just need to officially define some of the de facto behaviours Sure, as soon as the all the different ISA people officially define some of the de facto behaviors. UB isn't in the standard "just because" it's in the standard because there is no apparent underlying standard.
- cryptonector 8y ago
  Aliasing rules, for example, have nothing to do with ISAs. Neither do pointer comparison rules, and many others besides. The rule about memcmp() with invalid pointers by length zero does have to do with actual systems, but it can still be standardized and the vendors with now-non-compliant memcmp() implementations just have to fix it. This has happened before (e.g., snprintf()), so the ISA thing is a total cop-out.
  - zlynx 8y ago
    Weird ISAs are exactly why you cannot compare pointers. Segmented memory for one. Or imagine an OS and compiler that implemented automatic overlay switching. With that and PAE on 32-bit x86 systems you could have special "far overlay" pointers returned from malloc calls which would map in different 1 GB overlay sections when accessed. Aliasing rules are important in some ISAs too. Like weird DSPs. Imagine a system where 32-bit objects can't even share the same memory space as 8-bit objects. Casting a pointer to a different sized type is completely meaningless there. Of course programming such a weird thing is usually done in assembly, but there are C compilers.

dbaupp 8y ago

> In the case of rust we get to call these “compiler bugs” whereas in the C-language world such occurrences are more often labeled “undefined behavior”. C has both compiler bugs and undefined behaviour. Undefined behaviour is an inherent property of the C standard, while a compiler bug is a property of the implementation (a place where it doesn't match the standard). A valid argument along the same lines might be that the Rust compiler has existed for less time and is used less than C compilers, and therefore is more likely to contain bugs. > Because it is a newer language, it does not have (afaik) tools like gcov that are so helpful for doing machine-code testing. Coverage tools work on Rust, such as kcov. I'm not sure of the state of gcov itself though. > Nor are there multiple independently-developed rust compilers for diversity testing. Isn't diversity testing only necessary/good because there are many C compilers? Using your phrasing, if the code compiles and runs correctly (i.e. every single machine instruction is checked) with the one Rust compiler that exists, then it works. There's definitely many reasons why a language having multiple compilers is good, but I think "diversity testing" is circular logic.