4 ms·
Problem is that when you use C you get the low level coders on board relatively easily. Not always the case in other languages
by ludamad 10y ago
Problem is that when you use C you get the low level coders on board relatively easily. Not always the case in other languages
- pjmlp 10y agoWhen I started programming, C was just yet another systems programming language. Low level coders were using straight Assembly. I find ironic to see such statements about 40 years later.
- nickpsecurity 10y agoThen Cyclone or any of safe C subsets/variants.
- jjnoakes 10y agoCyclone is no longer active last time I checked. Or is it? What other safe C subsets/variants are out there which are actively being worked on? Cyclone and bit-c interested me greatly so pointers would be appreciated.
- cvwright 10y agoThe author of Cyclone seems to suggest that Rust is the current path forward: http://trevorjim.com/unfrozen-cyclone/ http://trevorjim.com/unfrozen-cyclone/ > Cyclone was an early attempt to create a programming language at the level of C, combining manual memory management with complete static memory safety. You can think of it as one step on the path that Rust and other languages have continued, one that I believe will eventually replace C, eliminating a host of severe security problems.
- nickpsecurity 10y agoCyclone, particularly its memory management, was one of the inspirations for Rust. That said, there's no way in hell Rust is a C replacement for people sold on C itself. There's people that need safe, fast, systems code. Rust can probably handle that. Then, there's people that think C is best language or don't want to learn something too different. They're not switching to Rust under any circumstances. The safer C's are useful for those people. Still have to force or pay them to do it as the C zeal is so strong. Yet, the smaller the adjustment, the more likely the uptake. Worked for C and Java vs others that clean-slated things.
- nickpsecurity 10y agoIt's not. Like most of academic ones, it can be picked up or clean-slated if people really want it. The authors tend to move on, though, as in BitC (unfortunately...). I have some others for you, though. Most research is on automatically transforming C instead of a safer, manually-done C. Best are these: https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/ http://sva.cs.illinois.edu/downloads.html http://sva.cs.illinois.edu/downloads.html http://dslab.epfl.ch/proj/cpi/ http://dslab.epfl.ch/proj/cpi/ Paper mentioning several of the safe C's, including those like Vault you can't have: https://pdfs.semanticscholar.org/a890/a850dc78e65e26f8f4def435b17094ce08cf.pdf https://pdfs.semanticscholar.org/a890/a850dc78e65e26f8f4def4... Galois, as usual, graciously open-sourced two of theirs (Ivory & Tower) that's already fielded in real world: http://ivorylang.org/ http://ivorylang.org/ Popcorn and TALC are older ones in prototype form: https://www.cs.cornell.edu/talc/releases.html https://www.cs.cornell.edu/talc/releases.html Someone here showed me this one I haven't evaluated but is used in compiler front-end: https://eigenstate.org/myrddin/ https://eigenstate.org/myrddin/ The C0 one used in Verisoft is embedded in vc0compiler-trunk probably. They did great things with it but I haven't been brave enough to try to retrieve it ;). http://www.verisoft.de/VerisoftRepository.html http://www.verisoft.de/VerisoftRepository.html So, altogether, what remains is quite scattered and prototype form. Plus, you still have to rewrite the software. So, I've mostly been recommending people apply Softbound, SAFECode, and CPI to their code just to see what happens. If it still works and fast enough, then just use it as it covers most bases. Also, contributing to those three's codebase is a very, wise move with potentially large impact.