However I'm all for experimental research projects developing alternative solutions.
But this is yet another bug that could not exist at all in a language with automatic memory management. And there are lots and lots of those bugs.
What we need is not to have knee-jerk reactions akin to angry mops carrying flaming torches and sharpened pitchforks. What we need is to praise the excellent work researchers are doing and to offer our time and/or money into:
a) more security research,
b) development of experimental alternatives written in memory safe languages,
c) yet more security research except this time on the experimental counterparts,
d) thorough testing of the experimental counterparts to ensure functional compatibility.
Maybe a few years down the line we will have something usable in a few bleeding edge Linux distributions, but it will be even longer still before it will have the backing of Debian, RHEL and SLES.
C only became a thing in computing after UNIX workstations became popular.
Before it, there were quite a few safer systems programming languages to choose from, that got steam rolled by C adoption in OS SDKs.
Due to its relation with UNIX, it will most likely happen with Apple (Swift), Microsoft (.NET Native, System C#, C++/GSL), Google (Java FTW on Android, Go) than any other OS vendor.
But I am also looking forward any of them pick D, Rust, <whatever safe lang> in the process.
This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html
I also feel the pains that Android teams imposes on the NDK users to use it as little as possible.
If you bothered to read the contents of the link that you pushed.
"Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need"
Also Android Java is nowadays AOT compiled to native code. So whatever C and C++ dependencies there are, could certainly eventually be replaced if there were willingness to do so.
Besides, have you ever tried to implement libc in ANSI C, without language extensions and a sprinkle of Assembly?
I have never attempted to put together a full libc in ANSI C, no. My experience there is limited to putting together parts of it for various microcontrollers, where I was more or less bound to ANSI C and chose to use no assembly.
That's a long way of saying, what's your point? And why do you feel the need to get personal?
Non native speaker here.
As I mentioned in the reply and in another thread, I do use the NDK, but I wouldn't if there were better alternatives.
30 years ago those microcontrollers would probably be programmable in Assembly and Forth, Pascal, Basic and C dialects. At least when I think about Z80 like ones.
C popularity pre-dates workstations. DEC (Digital Equipment Corporation ) , maker of popular mini computers, used it extensively.
Yes Apple runs on top of BSD, because they weren't able to write a new OS and had to buy one, which happened to be built on top of BSD.
Once upon a time they had their OS written in Object Pascal, but then they decided to rewrite it in C to welcome those UNIX devs.
Nothing prevents them to rewrite parts of the OS in Swift after the language gets more mature.
It is only a question of willingness, political will and money.
It was a mix of Object Pascal and Assembly. The Pascal extensions that Borland later adopted in TP 5.5.
Search for Pascal.
Cherry picked from the search results
http://www.folklore.org/StoryView.py?project=Macintosh&story...
The fact that many C programmers forget, is that it is impossible to implement the C runtime or an OS with pure ANSI C code.
Somehow it is ok for C to use Assembly and compiler specific extensions, but not for other systems programming languages to do the same.
I don't understand your last comment. I am not saying that the OS doesn't qualify as "written in Pascal" because it contains assembly. I am saying it doesn't qualify because it didn't contain Pascal. The early versions were subject to absurd space constraints that required everything to be written in assembly. My understanding is that high level languages started to be used for parts of the OS later on, but it remained predominantly assembly until well after the PowerPC transition.
It was the Lisa that was written in Pascal.
http://www.folklore.org/StoryView.py?project=Macintosh&story...
The only reason to get a C compiler for CP/M, MS-DOS or Amiga was to be able to bring work home from those expensive workstations at work or university.
Not on my country, it was all about Borland compilers, even in the Windows 3.x days.
Microsoft was even the last vendor to add support for C++ on the last MS-DOS version of Microsoft C, version 7 if I remember correctly.
But you can't simultaneously argue that C wasn't used for PC platform development in the 1980's and that Borland C was dominant.
I never said directly I was referring to Borland C, actually it was all about Turbo Basic and Turbo Pascal.
I and a few others did use Turbo C, but we jumped right into Turbo C++ the year thereafter, as we could not envision using plain C after having done systems programming in the other Borland languages.
C was left for programming classes, usually trying to convince the teacher to use C++ instead for projects, sadly it only worked occasionally.
I imagine if they would, they would put more money into the problem: either fund linux development or created more of a market for commercial server operating systems (which can still be open source, at least in some interpretations of the term), for example.
May be US (as de-facto main government-level actor in IT and internet) could create voluntary certification that opened up companies to such liabilities? Small startup operating from a garage — no certification necessary, but users are aware that no one is guaranteeing anything. IBM? Level A certification which they advertise everywhere, with billions of dollars in potential fines.
I even feel the breath of having Ada (the language) enforced over all of us again, and similar ideas...
(Not that Ada is so bad as a language, it's more about the ideas of enforcement and top-down control...)
Why do "we" have to agree? If somebody really believes this is necessary, why don't they just do it?
Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
> I assume he would argue this is a matter of shitty developers, not a shitty language.
All developers are shitty.
(For my projects I prefer D, but Rust has a point here)
I've heard someone in real life say "git just isn't there yet", so I couldn't resist humoring myself with this comment, sorry.
I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain.
Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.
However, it is very hard to avoid C++ developers that don't follow the modern C++ mantra to use it as if it was C, specially in the enterprise space.
You end up with "C compiled with C++" code style, which usually isn't subjected to any kind of code reviews or static analysis.
There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.
Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs.
By the way, glibc's code is too horrible to be read - musl is a more modern alternative.
And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the...
The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility?
Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable?
It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.
http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf
"CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."
Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...
Considering the time and effort it would take to safely and completely replace glibc with a new implementation, and the limited scope of its effect on Internet-wide security, it would be more productive to require the kernel itself to support patches like PaX, Exec Shield, or grsec in general, so that all applications (not just ones made with a specific language) would have stack-smashing protection.
The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes reach a broader number of use cases with less effort, and so we get along okay.
Likewise, we know that no matter what language we use, there will be at some point a problem with regard to accessing memory, and so we put protections in place to limit the scope of those attacks in a broad sense. It's a more effective mitigation for a greater number of use cases. It is not a panacea.
In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optimization.
I also think that when writing C, and C++ it makes a lot of sense to restrict oneself as much as possible a la the kinds of standards in the Google Style Guide, or NASA's style guide.
Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle.
So my theory is that it's not so much that people are especially inclined towards starting projects in C, but that projects in C have fewer barriers to distribution and thus adoption.
By natural selection, C code spreads and becomes standard; programs in Java, JS, Ruby, Haskell, Ocaml, etc. don't tend to leave their native ecosystem.
I don't think I'm immune to the hazards inherent in the language. I try my best be aware of them and to write safe code, and still find myself introducing a segfault now and then. Luckily, tools like valgrind and Coverity can really help to catch these kinds of issues early (of course, they can't catch everything, but I've been amazed by just how much they do catch).
Sure.
---
Compelling features:
- Unrivaled portability (yes, contrary to folklore C - and to a lesser extent C++ - is more portable than Java)
- Excellent libraries
- Excellent documentation and learning resources
- Unrivaled tooling
- perfect mapping to how the computer works
- Unrivaled performance (other than Rust)
- exceptional, engaging, and intelligent community (specifically referring to the cpp community)
---
Why start a C++ project today?
- you want to write a web browser
- you want a platform agnostc GUI
- you want to learn OpenGL or Vulkan
- you want to use Unreal and you're not a visual learner
- you're want to write the business logic for a cross platform application and share as much code as possible
- you're implementing you're own programming language
- your implementing an algorithm or data structure you've been studying
- you're bored
- you like programming in C++
- you want to learn template meta-programming
- you want to learn functional programming
- you want to learn how to write a device driver
- you need the performance
- you are not writing mission critical software (aka 99% of all side projects)
- you're a curious person
- you're a contrarian and everyone you know uses Java
- you want to become a more well-rounded engineer
- you want to learn about the ins and outs of language design and features
- you want make a lot of money
- you only know C++
Those are a few reasons. Hope that helps you solve your puzzle.
PS: Do the anti-C people realize that a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Yeah, you have to program "unsafe" code eventually. Those nice high level abstractions are not omnipresent, you know. They need something to abstract.
> a kernel in Rust/Nim/whatever would be under a big unsafe block anyways?
My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less. I agree we should minimize and encapsulate loosely checked code as best we can.
For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs.
In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs.
There are other options, but they are either commercial (e.g. Xamarin), or require lots of DYI hacking with the SDKs toolchains.
So if you want to remain productive and not pay for the commercial solutions, there aren't any other alternatives.
Which means, even I with my safety rants, end up using them for my mobile OS hobby coding.
However if I would be doing this commercially, Xamarin would be my first option.
You don't even have to rename .m to .c, but you can.
On Linux it's easy: It is (or was, until very recently) the least sucky alternative. All others have (or had) issues with OS support (C#), distribution (Java: OpenJDK vs. Oracle JDK; Python: 2.5 to 3.4 parallel in use by different distributions; Vala: Every compiler update breaks the language; etc. pp.), availability of libraries (Ruby, PHP, Perl… for anything that's not their speciality) or general obscurity (OCaml, …).
Go and Rust (and JS, C# and Vala recently) seem to be changing this, thankfully. But those too will depend on the availability of high-quality bindings for all the C(++) libraries you have to use to get anything substantial done.
Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.
This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct.
If written properly C++ is not unsafe, then written properly C is not unsafe.
Eg. Don't use C++ as C with vectors, use C++ with the more modern language features:
It's the difference between:
// where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others.
It's the difference between:
std::string A = "ab" + std::string("c");
// And:
char Buffer[512] = {};
strcat(Buffer, "ab");
strcat(Buffer, "c");
std::vector<uint8_t> SomeData = { 1,2,3 }
std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end());
// and:
std::vector<uint8_t> SomeData = { 1,2,3 }
std::vector<uint8_t> OtherData;
OtherData.reserve(3);
memcpy(...)
std::string A = "ab" + std::string("c");
// And:
char Buffer[512] = {};
strcat(Buffer, "ab");
strcat(Buffer, "c");
std::vector<uint8_t> SomeData = { 1,2,3 }
std::vector<uint8_t> OtherData(SomeData.begin(), SomeData.end());
// and:
std::vector<uint8_t> SomeData = { 1,2,3 }
std::vector<uint8_t> OtherData;
OtherData.reserve(3);
memcpy(...)
It's not; as soon as code uses (for instance) references, you're running the memory-unsafety gantlet. E.g. even something super-modern like
for (auto& thing: vector)
Some people like to say that these bugs are trivial to avoid ("who would write code like that?!"), but they miss the insidious (and common) case: when code several layers down the call stack (in some arbitrary callback assigned at runtime, say) grows the vector/map from under you.
[1] not talking about memory safety, but as a general "probability of having a defect".
There certainly is a spectrum.
Okay. Based on my current project (Porting AVS out of shit-tier Microsoft C++). I want a region of memory in which I can treat as a bitmap and set pixels at given location to given colours. I know of no other language that gives me this block of memory to draw into. That's probably because I don't know enough. Most languages seem to tout how immutable things are. That's a big word for many people and it just means "does not change".
If other languages want my attention then maybe they need more than a "Hello, World!" and some string processing. Show me your malloc equivalent and see if I can go from there.
http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_a...
https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#...