Our great sponsors
CompCert | gcc | |
---|---|---|
36 | 81 | |
1,761 | 8,704 | |
1.6% | 1.9% | |
7.3 | 9.9 | |
20 days ago | 1 day ago | |
Coq | C | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
CompCert
-
Differ: Tool for testing and validating transformed programs
A big problem is that proving that transformations preserve semantics is very hard. Formal methods has huge potential and I believe it will be a big part of the future, but it hasn't become mainstream yet. Probably a big reason why is that right now it's simply not practical: the things you can prove are much more limited than the things you can do, and it's a lot less work to just create a large testsuite.
Example: CompCert (https://compcert.org/), a formally-verified compiler AKA formally-verified sequence of semantics-preserving transformations from C code to Assembly. It's a great accomplishment, but few people are actually compiling their code with CompCert. Because GCC and LLVM are much faster[1], and have been used so widely that >99.9% of code is going to be compiled correctly, especially code which isn't doing anything extremely weird.
But as articles like this show, no matter how large a testsuite there may always be bugs, tests will never provide the kind of guarantees formal verification does.
[1] From CompCert, "Performance of the generated code is decent but not outstanding: on PowerPC, about 90% of the performance of GCC version 4 at optimization level 1"
- So you think you know C?
-
Can the language of proof assistants be used for general purpose programming?
Also a C compiler (https://compcert.org/). I did exaggerate bit in saying that anything non-trivial is "nearly impossible".
However, both CompCert and sel4 took a few years to develop, whereas it would only take months if not weeks to make versions of both which aren't formally verified but heavily tested.
-
A Guide to Undefined Behavior in C and C++
From my experience, while many MCUs have settled for the big compilers (GCC and Clang), DSPs and some FPGAs (not Intel and Xilinx, those have lately settled for Clang and a combination of Clang and GCC respectively) use some pretty bespoke compilers (just running ./ --version is enough to verify this, if the compiler even offers that option). That's not necessarily bad, since many of them offer some really useful features, but error messages can be really cryptic in some cases. Also some industries require use of verified compilers, like CompCert[1], and in such cases GCC and Clang just don't cut it.
-
Recently I am having too much friction with the borrow checker... Would you recommend I rewrite the compiler in another language, or keep trying to implement it in rust?
CompCert sends its regards
- Rosenpass – formally verified post-quantum WireGuard
-
OpenAI might be training its AI technology to replace some software engineers, report says
But that's fine, because we can do even better with things like the CompCert C compiler, which is formally proven to produce correct asm output for ISO C 2011 source. It's designed for high-reliability, safety-critical applications; it's used for things like Airbus A380 avionics software, or control software for emergency generators at nuclear power plants. Software that's probably not overly sophisticated and doesn't need to be highly optimized, but does need to work ~100% correctly, ~100% of the time.
-
There is such thing called bugfree code.
For context, CompCert is a formally verified compiler. My former advisor helped with a fuzzer called CSmith which found plenty of bugs in GCC and LLVM but not in CompCert.
-
Checked C
Does anybody know how does this compare to https://compcert.org/ ?
-
Proofs about Programs
This is a common property for proof-oriented languages. Coq shares this property for instance, and you can write an optimizing C compiler in Coq: https://github.com/AbsInt/CompCert .
gcc
-
C++ Safety, in Context
> It's true, this was a CVE in Rust and not a CVE in C++, but only because C++ doesn't regard the issue as a problem at all. The problem definitely exists in C++, but it's not acknowledged as a problem, let alone fixed.
Can you find a link that substantiates your claim? You're throwing out some heavy accusations here that don't seem to match reality at all.
Case in point, this was fixed in both major C++ libraries:
https://github.com/gcc-mirror/gcc/commit/ebf6175464768983a2d...
https://github.com/llvm/llvm-project/commit/4f67a909902d8ab9...
So what C++ community refused to regard this as an issue and refused to fix it? Where is your supporting evidence for your claims?
- Std: Clamp generates less efficient assembly than std:min(max,std:max(min,v))
-
Converting the Kernel to C++
Somewhat related: In 2020 gcc bumped the requirement for bootstrapping to be a C++11 compiler [0]. Would have been fun to see the kernel finally adopt C++14 as the author suggested.
I don't think that Linus will allow this since he just commented that he will allow rust in drivers and major subsystems [1].
I do found it pretty funny that even Linus is also not writing any rust code, but is reading rust code.
I would have hoped see more answers or see something in here from actual kernel developers.
0: https://github.com/gcc-mirror/gcc/commit/5329b59a2e13dabbe20...
-
Understanding Objective-C by transpiling it to C++
> They’re saying that a lot of the restrictions makes things much harder than other languages. Hence the general problem rust has where a lot of trivial tasks in other languages are extremely challenging.
Like what? So far the discussion has revolved around rewriting a linked list, which people generally shouldn't ever need to do because it's included in the standard lib for most languages. And it's a decidedly nontrivial task to do as well as the standard lib when you don't sacrifice runtime overhead to be able to handwave object lifecycle management.
- C++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...
- Rust: https://doc.rust-lang.org/beta/src/alloc/collections/linked_...
> No need to get defensive, no one is arguing that rust doesn’t do a lot of things well.
That's literally what bsaul is arguing in another comment. :)
> You’re talking up getting a safe implementation in C, but what matters is “can I get the same level of safety with less complexity in any language”, and the answer is yes: Java and c# implementations of a thread safe linked list are trivial.
Less perceived complexity. In Java and C# you're delegating the responsibility of lifecycle management to garbage collectors. For small to medium scale web apps, the added complexity will be under the hood and you won't have to worry about it. For extreme use cases, the behavior and overhead of the garbage collector does became relevant.
If you factor in the code for the garbage collector that Java and C# depend on, the code complexity will tilt dramatically in favor of C++ or Rust.
However, it's going to be non-idiomatic to rewrite a garbage collector in Java or C# like it is to rewrite a linked list in Rust. If we consider the languages as they're actually used, rather than an academic scenario which mostly crops up when people expect the language to behave like C or Java, the comparison is a lot more favorable than you're framing it as.
> If I wanted I could do it in c++ though the complexity would be more than c# and Java it would be easier than rust.
You can certainly write a thread-safe linked list in C++, but then the enforcement of any assumptions you made about using it will be a manual burden on the user. This isn't just a design problem you can solve with more code - C++ is incapable of expressing the same restrictions as Rust, because doing so would break compatibility with C++ code and the language constructs needed to do so don't exist.
So it's somewhat apples and oranges here. Yes, you may have provided your team with a linked list, but it will either
-
Committing to Rust for Kernel Code
GCC is also written in C++, and has had C++ deps since 2013:
https://github.com/gcc-mirror/gcc/blob/master/gcc/c/c-parser...
- Spitbol 360: an implementation of SNOBOL4 for IBM 360 compatible computers
-
are most computer programming languages public domain, or do their creators get a say in what you do with them?
Compliers/Interpreters are also very commonly open source (here is the source code for a popular C compiler). That means you can even modify the compiler's code and change its behavior if you wanted to.
- Learn to write production quality STL like classes
-
Which compiler is conforming here?
according to this commit, the story here seems to be much more interessting than I initially anticipated.
-
My favorite C compiler flags during development
For a more detailed explanation, see [2]. (Also the inspiration for the above example,)
[1] https://en.m.wikipedia.org/wiki/Transitive_relation
[2] https://github.com/gcc-mirror/gcc/commit/50ddbd0282e06614b29...
What are some alternatives?
seL4 - The seL4 microkernel
CMake - Mirror of CMake upstream repository
coq - Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.
rtl8192eu-linux-driver - Drivers for the rtl8192eu chipset for wireless adapters (D-Link DWA-131 rev E1 included!)
unbound - Replib: generic programming & Unbound: generic treatment of binders
llvm-project - The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
corn - Coq Repository at Nijmegen [maintainers=@spitters,@VincentSe]
STL - MSVC's implementation of the C++ Standard Library.
vericert - A formally verified high-level synthesis tool based on CompCert and written in Coq.
cobol-on-wheelchair - Micro web-framework for COBOL
koika - A core language for rule-based hardware design 🦑
qemu