18 ms·
This has been tried many times before, and eventually all these attempts die a lonely death. Why use extensions anyway? If one desired the luxury of modern scri
by Dinux 9y ago
This has been tried many times before, and eventually all these attempts die a lonely death. Why use extensions anyway? If one desired the luxury of modern scripting languages, switch to C++, Rust, Go or one of the other alternatives the article mentions.
- pjmlp 9y agoBecause regardless how some of us might dislike C and its security related issues, the truth is that no one is ever going to rewrite UNIX systems in other language, nor the embedded systems where even C++ has issues gaining market share. So if one finally manages to get a safer C variant that finally wins the hearts of UNIX kernels and embedded devs, it is a win for all, even those that don't care about C on their daily work. Until it happens, that lower layer all IoT devices and cloud machines will be kept in C, and not all of them will be getting security updates.
- Dinux 9y agoI do not question the usefulness of C, I use it in my daily work. What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing, and don't need yet another non-standard way of writing the code. Safety is a good point, but the initiative doesn't even mention the word, and there is no reason to assume the C-for-All extension targets safety at all
- s73v3r_ 9y ago"What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing" I'm going to strongly disagree with that statement.
- saagarjha 9y agoI might have agreed with you if this was C++. C is a small enough language that most programmers can understand most of it.
- s73v3r_ 9y agoToyota was full of programmers that apparently "understood what they were doing."
- saagarjha 9y agoBad practices can carry over to any language. They’re clearly incompetent at using C, but that doesn’t mean that they won’t be incompetent in another language.
- ori_b 9y agoFair point, but changing the language won't change the amount of global state. and the associated complexity, nor will it make subsystem supervision work correctly. Changing the language will not prevent unbounded recursion or the associated stack overflows and subsystem failures. Changing the language will not fix mis-analysis of task switching overhead. And changing the language will not fix manufacturing issues with the PCBs. As far as I'm aware, one of the very few toolchains that even try to improve on this over C are Ada/SPARK.
- vvanders 9y ago> but changing the language won't change the amount of global state Global mutable state is marked as Unsafe in Rust. > nor will it make subsystem supervision work correctly Erlang is built specifically around this concept. Perfect is the enemy of good here, throwing out a whole language due to one case doesn't help anyone.
- ori_b 9y ago> Global mutable state is marked as Unsafe in Rust. It's also the simplest way to avoid dynamic allocation and the associated OOM issues. So, short of doing static analysis to bound heap usage at compile time, that makes things worse. And Toyota already got the static analysis wrong for their stack usage. At least globals will fail to compile if they won't fit.
- 9y ago
- pjmlp 9y agoEven ANSI/ISO C working group acknowledges that “thrust the programmer” doesn’t quite work.
- gmueckl 9y agoThis is because trusting the programmer is fundamentally wrong, no matter the programming language. In any good development process the actual coding is the least amount of work - for a reason.
- pjmlp 9y agoThis was the statement I was referring to. <quote> Spirit of C: a. Trust the programmer. b. Do not prevent the programmer from doing what needs to be done. c. Keep the language small and simple. d. Provide only one way to do an operation. e. Make it fast, even if it is not guaranteed to be portable. The C programming language serves a variety of markets including safety-critical systems and secure systems. While advantageous for system level programming, facets (a) and (b) can be problematic for safety and security. Consequently, the C11 revision added a new facet: => f. Make support for safety and security demonstrable. </quote> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf
- gmueckl 9y agoOkay, this makes me rethink my previous statement. There are two kinds of trust here: A low level programming language should not impose restrictions on the code that prevent the programmer from doing what needs to be done, even if it looks wrong. This is how I read the 'Spirit of C" that you quoted. And certain applications would be impossible to write without it. But you need a development process to make sure that your system does exactly the right thing. So the quote should read "trust the process" rather than "trust the programmer".
- kerkeslager 9y agoWhat makes you think that a safer C variant would win the hearts of UNIX kernels and embedded devs any more than C++ (which started as just a C variant).
- BoorishBears 9y agoSimplicity, no STL or templating, no OOP connotations I don’t necessarily think it would, but if it did, those would all be reasons
- BruceIV 9y ago[actually on the Cforall team] This is basically our pitch -- the last 30 years of language design features applied to a language that is not only source-compatible with C (like C++), but actually maintains the procedural paradigm of C (unlike C++) -- idiomatic C code should require minimal to no change to make it idiomatic Cforall code, and skilled C programmers should be able to learn the extension features orthogonally, rather than needing to figure out complex interactions between, say, templates and class inheritance. We are working in the same space as C++, and do draw inspiration from C++ where useful, but with the benefit of decades of watching C++ try things to see where the important features are. There's also some really neat language-level concurrency support; work is ongoing on new features and a shorter summary, but you can see one of our Master's student theses for details: https://uwspace.uwaterloo.ca/handle/10012/12888 https://uwspace.uwaterloo.ca/handle/10012/12888
- aidenn0 9y agothe existence of exceptions seems to bely the idea of minimal changes to make idiomatic C code idiomatic Cforall code. While C does have longjmp and friends, usage of them is hardly idiomatic, so most C code assumes no non-local tranfer of control happens when calling functions. Coding with non-local transfer of control and without require very different idioms.
- wolfgke 9y agoIt would probably be much smaller than the gigantic C++ standard.
- zombieprocesses 9y ago> So if one finally manages to get a safer C variant that finally wins the hearts of UNIX kernels and embedded devs A safer variant wouldn't be C. What makes C great for OS development is that it is just a step above assembly and you as a developer are given tremendous amount of power to do good and evil. C#/Java are programming languages with training wheels and it's great for application development. But for low level coding required for OS, network stacks, databases, etc, you really have to take the training wheels off. I suppose you can try and make the C type system more stringent, but then it wouldn't be C. And considering they are aiming for backwards compatibility with existing C and its immense code infrastructure, they will have to keep the "flaws" in c for all. Time would be better spent making the libraries/kernel/etc sturdier but if they can pull it off and win the hearts and minds of OS developers, then so be it. Also, people have been trying to sideline C for decades. Each attempt has only reinforced C's standing and reminded us why C is so essential for OS development. Anyone remember the ill-fated attempt by Sun with their JVM centered JavaOS?
- golergka 9y agoA full time C#, can confirm. It's an awesome business logic langauge, but the hot path eventually gets rewritten in a very C-like style, with all Linq, exceptions and allocations thrown out.
- dralley 9y agocounterexample: RedoxOS Although it's more along the lines of Plan9 - a unix-like system that ignores the bits of POSIX that really suck.
- pjmlp 9y agoIf it doesn’t support 100% POSIX it isn’t UNIX. Also how would you make memcpy() safe in a POSIX implementation on Redox?
- aidenn0 9y agoThen most linux distributions aren't UNIX, as they do tend to deviate from POSIX in places.
- nine_k 9y agoIt's GNU/Linux, and GNU = GNU is Not Unix. So it says Not Unix right on th tin.
- boomlinde 9y agoTo be perfectly fair, if it isn't UNIX it isn't UNIX.
- IAmLiterallyAB 9y agoAlmost nothing is 100% POSIX. Most Linux distros aren't. Who cares as long as the important bits are there.
- Gibbon1 9y ago> Also how would you make memcpy() safe Easy, don't have memcpy().
- zzzcpan 9y agoWhich means that minimal requirements to win kernel and embedded devs is to integrate well with the rest of the C ecosystem, including myriad of C compilers and to be really well suited for low level work. This excludes pretty much all ideas, but meta languages that produce C code. Might even be necessary to promote the language itself not as a new language, but as a meta preprocessor for C to avoid alienating developers. But realistically this is not feasible nor necessary. There are much more feasible ideas to improve safety, than forcing half of the world to learn a lot of new things and change.
- pjmlp 9y agoUnfortunately not all systems are Solaris running on SPARC, with memory protection enabled. Something akin to Intel MPX.
- pjc50 9y agoThe trouble with a "safer C variant" is that it must remove features, or at least more heavily constrain programs to a safer subset of the language. This makes it not backwards-compatible. I think the only successful "subset of C" is MISRA.
- pjmlp 9y agoMaybe Frama-C as well.
- fao_ 9y agoI remember reading a paper from around 2007 that asserted that most of MISRA did not catch or significantly prevent major bugs in code, indeed it asserted that much of the standard was useless. I am failing to find it now, as I cannot remember what terms I used, and I am not at a library computer and therefore I cannot search behind paywalls beyond abstracts.
- zzzcpan 9y agoCannot say that this is unexpected, but I was interested to find some papers, presumably these two: Assessing the Value of Coding Standards: An Empirical Study [1], Language subsetting in an industrial context: A comparison of misra c 1998 and misra c 2004 [2] [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.559.7854&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.559... [2] http://leshatton.org/Documents/MISRA_comp_1105.pdf http://leshatton.org/Documents/MISRA_comp_1105.pdf
- pjmlp 9y agoInteresting, thanks for the papers.
- duneroadrunner 9y agoSaferCPlusPlus[1], for example, is a safe subset of C++ that has compatible safe substitutes for C++'s (and therefore C's) unsafe elements. So migrating existing C/C++ code generally just requires replacing variable declarations, not restructuring the code. For C programs, one strategy is to provide a set of macros to be used as replacements for unsafe types in variable declarations. These macros will allow you, with a compile-time directive, to switch between using the original unsafe C elements, or the compatible safe substitutes (which are C++ and require a C++ compiler). The replacement of unsafe C types with the compatible substitute macros can be largely automated, and there is actually a nascent auto-translator[2] in the works. (Well, it's being a bit neglected at the moment :) Custom conventions using macros to improve code quality are not that uncommon in organized C projects. Right? But this one can (optionally, theoretically) deliver complete memory safety. So you might imagine, for example, a linux distribution providing two build versions, where one is a little slower but memory safe. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
- s73v3r_ 9y agoThey're not going to rewrite any of them in this dialect, either.
- snarfy 9y agoYou can use c++14 on embedded devices just fine, and people do.
- saagarjha 9y agoYou can, as long as you stay away from templates and lambdas and STL containers; in short, most of the reasons you’d use C++.
- aurelian15 9y agoSTL, RTTI and Exceptions should be avoided on embedded platforms (talking about 8 bit µCs here). I've extensively used both templates and lambdas on 8 bit AVRs (both the Tiny and Mega series); actually, writing templated code for µCs is a great way to avoid overhead stemming from function pointers etc. while still having well maintainable code.
- michaelcampbell 9y ago> Because regardless how some of us might dislike C and its security related issues, the truth is that no one is ever going to rewrite UNIX systems in other language Now will they in this.