This seems to be a successor to CCured from 2005, a project partially funded by Microsoft. [1]
The general idea is straightforward: "The unchecked C pointer type * is kept and three new checked pointer types are added: one for pointers that are never used in pointer arithmetic and do not need bounds checking (ptr), one for array pointer types that are involved in pointer arithmetic and need bounds checking (array ptr), and one for pointer types that carry their bounds with them dynamically (span)." So this is really a new language derived from C, to which programs can be converted.
This is basically a good idea, but it's only useful if pushed hard by somebody like Microsoft. People won't convert without heavy pressure.
I thought so too, but looking at their paper, they have an impressive survey of prior approaches, and they explain their differences from CCured quite well. CCured used fat pointers, and apparently modified the data pointed to by WILD pointers (something I didn't know).
This seems interesting to me. I liked the way CCured did inference to document how you used and abused your pointers, but what it did with that information was maybe not ideal.
but I don't want to move my embedded C projects to C++. If I can use a language extension to get some extra confidence in my programs without changing the language im using then that's a compelling proposition.
The difference between a language extension, and a new language, is one of degree, not kind. Personally, since the semantics of this "extension" go to the core of what one does in C, I consider Checked C a new language.
I agree, in principle. But reading over this document, the changes can be made in an incremental fashion. And with far less impact than switching to using C++ just for these (assuming equivalents exist) features.
Enable extension
Add `checked` to array declarations. (for the simplest
case they've implemented).
Converting to C++ also means making sure you have `extern "C"` in your function declarations to get around C++'s name mangling when calling C libraries. Among other, potential, source level changes. Or, similarly, making sure your C (now C++) library can be called correctly by C projects that depended on it.
I'm not sold on this project as we haven't seen any results of course, but the approach is simpler than switching to C++.
C++ is an altered and extended form of C, thus I would say it is more accurate to call it a superset, rather than a subset. I'm not using precise definitions here.
And of course, but those will come in time. The point of it is that C++ isn't any safer (And actually, I would say is more risky in some aspects, because of the differences between (For example) the UB in C and C++), while Checked C is guaranteed to be safer, to a certain degree.
Indeed, checkedc also introduces these 3 new pointer types (ptr, array-ptr and span). It also introduces invariants on variables, arguments and return values:
Reasoning about the correctness of programs with declared bounds sometimes requires reasoning
about simple aspects of program behavior. To support this, lightweight invariants are added to Checked C. A lightweight invariant declares a relation between a variable and
a simple expression using a relational operator. An example would be the statement x < y
+ 5. Lightweight invariants can be declared at variable declarations, at assignment statements,
for parameters, and for return values. Checked C is extended with rules for checking
these lightweight invariants. Just as type checking rules are defined by the programming
language, so are rules for checking lightweight invariants. The checking of the correctness of
programmer-declared bounds is integrated with the checking of invariants.
Being pushed by Microsoft could be exactly the reason not to convert, for many people. Especially when there is no shortage of alternatives that are backed by a bit more benevolent entities (Rust, and many other less known variants).
I don't think this project is an instance where this is an important aspect, but in general I do agree that some caution is warranted when using an open source project backed by a corporation (Microsoft or anyone else) in your code. As someone who was recently burned by what happened to RoboVM[1], I am now always careful to check for any CLAs that are required to contribute to open source projects before I decide to use them in anything important.
The fact than you can fork is nice, but if the project is too reliant on the paid staff and doesn't have enough community surrounding it to survive getting dropped by its benefactor, you better hope you have the resources to maintain it yourself. This can happen even with no ill-intention involved, but the whole RoboVM debacle has convinced me that Embrace, Extend, Extinguish is not quite dead at Microsoft.
How many startups have been killed by other corporations, including Google, FB and friends?
The RoboVM situation, while unfortunate is a lesson for people not to rely on proprietary tooling for portable projects.
While I mostly code on JVM and .NET languages during the day, I use C++ for my hobby projects on mobile OSes.
The reason being that C++ is an open standard and officially supported in all SDKs, no need for third party layers like RoboVM.
A few similar lessons with my time spent on programming languages that weren't first party on platform SDKs, made me always choose first party languages, if I have decision power in the selection process.
> How many startups have been killed by other corporations, including Google, FB and friends?
Yeah, that's why I said "Microsoft or anyone else". The only other time I mentioned Microsoft was in reference to RoboVM, which doesn't have much to do with Google or Facebook.
> The RoboVM situation, while unfortunate is a lesson for people not to rely on proprietary tooling for portable projects.
I agree, but the fact that RoboVM started off open source with a GPL licensed compiler was one of the main reasons I chose it. It's my own fault I didn't look to see how contributions were structured, or notice that very little code came from outside RoboVM, sure. That's why I'm advising caution in similar situations.
Where did Microsoft employ embrace or extend before extinguishing RoboVM? They bough Xamarin for Xamarin, and ended up with a RoboVM they didn't want. There was no RoboVM strategy there.
To put things in perspective, consider than from web browsers and languages, to their respective ill-fated mobile OS efforts, nothing Mozilla created has ever gotten more adoption than something MS created.
Just FYI, Statista is a private company. You may be thinking of http://destatis.de/, which is the homepage of the German federal office for statistics.
In reply to myself: The times are changing indeed. It seams that HN-ers started liking Microsoft. Whenever I post some concern, even if only mild, there is first a few upvotes, and then a bunch of downvotes.
Microsoft became the darling of the community, OR, in addition to embracing open source, they embraced voting ring tactics. These are two explanations I have, maybe there is another. Maybe my criticism really was obnoxious...
Maybe it's just because yes, we all remember the 90s. But today is not necessarily the 90s. It was a lot more recent that Google was a relatively benevolent company, and we've all seen how that's changed.
And the thing about open source projects, is just that. They're open source. If the wider community takes hold of them, there's not much Microsoft can do. Because then you just see a fork.
You don't have to be a fan of Microsoft to simply appreciate the contribution to open software, as it is.
Forced updates for Windows 10 burned all the credibility Microsoft was slowly regaining. Whatever might be going on in there, they still have enough of the old strongarm bullying monopolist in their collective corporate character that their good works really cannot be trusted over the long term.
My Android has forced updates. I have to put my phone in airplane mode before each reboot and kill the process to prevent it. Chrome has forced updates. A lot of things have forced updates these days, and nobody bats an eye about it. Microsoft does it, everyone loses their minds.
And 'forced' is a stretch anyways, how to block it is well documented, and was months in advance. And you can revert, something Google and others will not let you do.
I also deleted all the Google apps I could find on my Android phone, and I avoid storing any of my personal data on it, because Google seems to believe it's their machine, not mine. I'd use some other mobile OS if I had any choice in the matter.
I have an Android 4.4 phone, Verizon/Google is trying to force my phone to install Android 5.1, a full version update to a version widely regarded as a lemon.
I paid for my phone. I paid for my Windows license. I paid a lot more for my phone, which Android is trying to forcibly update without my consent to a version which will cripple my phone's functionality substantially.
I'm angry about the idea that forced updates might become a normal practice, because that could lead to a situation where it's difficult to find much software I am willing to use.
"Power to the people" has always been the whole point of personal computing, as far as I'm concerned. Give people control over their data, their processes, their lives; that's why we're doing this, isn't it?
Power to the user is one aspect of personal computing. But with the rise of mobile and now IoT, the user has also become (increasingly) a 'consumer', and thus the software and hardware are getting more and more locked down. Hardware and software manufacturers will sleep easier at night when their products cannot (or can only limitedly) be modified.
I think the writing is on the wall. Computing devices will split into two diverging branches: one tailored for limited configuration and aimed at media consumption and use by non-tech users, the other providing (hopefully) full freedom to modify, aimed at IT co. and interested hobbyists. It will be quite some achievement if mechanisms to increase vendor control aren't increasingly integrated even into the devices in the second segment, as things like Intel ME/UEFI Secure Boot show.
pff.. they are "open source" just because they want to attract developers, because without developers writing apps for their platform, Microsoft will die (as any other platform). They are still just money-makers and nothing else, there is no any idea except money behind their movements to Open Source world, otherwise they wouldn't take revenues from Android.
Because ocdtrekkie was using Microsoft's open source strategy to imply that Microsoft is no longer pursuing the same goals as before. EugeneOZ explained that Microsoft's strategy does not preclude their earlier goals.
It's sad to see that despite open source (or free/libre..etc) software being around for so long, people still don't get it that money and freedom are not mutually exclusive. I would argue that contributing to open source for business reasons is perhaps even more beneficial for the software and community than just doing it for a hobby or some philosophy because companies pay people to even work on stuff that is not exciting / interesting.
As if these were orthogonal. My employer encourages me to contribute to open-source precisely because the open-source tools are the best for the job and thus allow us to make more money.
It's absolutely different case. Microsoft don't care if tools they use will be open-source or free - no. They only care if they can attract developers by playing role of "openSource company". It's not your case.
last time I checked Microsoft was a company (not a platform) and like any other it has to make money to survive. Your saying is applicable to every other company releasing open source code
Yes they are... And believe it or not people / companies can change. And changing to a more open culture even if the reasons for doing this is because they will cease being competitive if they don't is still a good thing. Open source these days not only makes sense technically and ethically but also economically... And that's a good thing.
And I absolutely agree with it. Even happy about that. Companies should make money, developers should make money - it's all the right things. I love money too :)
The only thing I'm talking about is honesty - MS is trying to show they love open-source just because they are so awesome and hackers, but in reality it's just profitable mask and they are glad to wear it.
I submit that Microsoft is staffed and led, in part, by talented software developers, many of whom are invested themselves in open source philosophy. When ideas make it into the light of day that reflect this internal culture, I think it is a cause for happiness. Let's use care when claiming to understand the actual decision making process in any complex organization, particularly one formed from many intelligent, autonomous agents. Certainly skepticism is healthy in general, but in this case it doesn't seem to serve a positive purpose.
I appreciate your efforts to register this account just to write this reply. But as it's just common words (each huge software company have developers who are involved to open-source projects), nothing has changed in my opinion - I'm still sure they wave "open-source" flag just to not loose developers for their platform and any their new standard or new language is a tool for vendor-lock (platform-lock) as it was before for years.
You are dismissive of "attracting developers" as motive. That has always been a marketing ploy of the open source camp as an alternative to a fully open philosophy i.e. information wants to be free.
Doesn't that look like an open source implementation? Or did I misunderstand something?
However:
> The compiler is not far enough along for programmers to "kick the tires" on Checked C. We do not have a installable version clang available yet. If you are really interested, you can build your own copy of the compiler:
Or maybe we stopped categorically demonizing some technology because of its provenience and started evaluating it based on criteria like usefulness and applicability.
You know, like if we actually take the "engineer" part of "software engineer" seriously instead of using it for everyone who once wrote a PHP page for his uncle.
He is "demonizing" some "typical PHP programmer". It's not the languages fault that it is allegedly often used by novices to start their first website project, and that by no fault of their own those novices do not have any appreciable CS education and thus build their programs like I build a sandcastle: keep trying random things until it does not fall over anymore.
The argument is exactly to make this difference. There is the technical and somewhat objective aspect of the language and its implementation, and there are the people who created the language, who use the language etc. A bad language can have a great community, and vise versa.
I had a go at this problem, backwards-compatible safe C, back in 2012.[1] It was discussed on the C standards mailing list, and the consensus was that it would work technically, but was politically infeasible. What I proposed was not too far from "Checked C", but the syntax was different.
I'd defined a "strict mode" for C. The first step was to add C++ references to C. The second step was to make arrays first-class objects, instead of reducing them to pointers on every function call. When passing arrays around, you'd usually use references to arrays, which wouldn't lose the size information as reduction to a pointer does.
Array size information for array function parameters was required, but could be computed from other parameters. For example, UNIX/Linux "read" is usually defined as
int read(int fd, char buf[], size_t len);
The safe version would be
int read(int fd, &char buf[len], size_t len);
In both cases, all that's passed at run time is a pointer, but the compiler now knows that the size of the array is "len" and has something to check it against. The check can be made at both call and entry, and in many cases, can be optimized out. In general, in all the places in C where you'd describe an array with a pointer with empty brackets, as with "buf[]", you'd now have to put in a size expression.
You could do pointer arithmetic, but only if the pointer had been initialized from an array, and was attached to that array for the life of the pointer.
char s[100];
char* p = s;
...
char ch = *p++;
Because p is associated only with s, the compiler knows what to check it against.
There was more, but that's the general idea. A key point was that the run-time representation didn't change; there were no "fat pointers". Thus, you could intermix strict and non-strict compilation units, and gradually convert a working program to strict mode.
This took less new syntax and fewer new keywords than "Checked C". I was trying to keep C style, adding just enough that you could talk about arrays properly in C.
Perl introduced a "strict" mode a long time ago. Although it doesn't force it on you, virtually all modern Perl programmers use it by default.
As an extra security feature Perl also supports "taint" mode, which "taints" all user-supplied data as potentially hazardous to the program. This was used more for CGI, but it's still a simple and powerful security feature. Unfortunately, it was never adopted like 'use strict' was because it would more often get in the way of the programmer.
The fundamental memory safety problem in C is that arrays are not first-class objects. They degrade to pointers when passed around. Yet any function which references an array has to know how big it is. Somehow. The language has no syntax for this. That's the big problem, and what I was addressing.
I wasn't arguing your point. I'm saying it's been proven that some new optional functionality can be adopted slowly and eventually become de-facto standard. (And that it might not get adopted if it gets in a programmer's way)
I've already been downvoted for this question, but I don't get the business case here. If you are worried about this, why not write code in modern C++ which has plenty of ways to make all sorts of issues like this safe ? Why stick to C at all?
C++ doesn't solve the problem. C++ papers over the problem with templates. You can still get raw pointers out of C++ objects, and for most APIs, you have to. The underlying language objects are still unsafe.
ok, so write C++ classes that don't let you access raw pointers. I mean I understand that C/C++ languages are less safe than, say, Java - but that is the whole point. The lesser safety gives you better performance. If you don't care about bleeding edge performance, you should probably choose Java or Python or some other language that is much more flexible and easier to use
No. That excuse has been bandied about for years, but it's wrong, as we're now seeing as Rust gets better. C's problems with arrays come from lack of expressive power in the language. C doesn't even let you talk about array size in parameters.
Many of C's painful design decisions come from trying to cram a compiler into a PDP-11 with 128KB (not MB) of memory for a process. Global analysis on a machine that small while retaining reasonable compile times was hopeless. This is no longer a limitation.
I think the thing is that the problems people are still using C to solve for are a different than the ones where people are using C++, Java, C#. Meaning if C++ was a better option then people would have switched to using C++ two decades ago. Yet C has historical deficiencies that could be fixed by smallish mostly painless extensions to the language.
You know, some people seem to scoff at replacement Cs. I'm kind of one of them. I know my reason(s) though. It's not about other languages as much as C itself. I've been with it for awful long time now and I used to think I kind of know my way around it. I've changed that line of thinking, because I know it's not true. I make a lot of mistakes, especially considering memory. At least (almost all of) my code isn't public-facing.
Since I thought I knew C very well, I came to realisation (due to many memory bugs/leaks) that maybe that's not the case after all. What is it then? I can get performance out of it, lots of it (that's one thing I know to do, somewhat at least). That's when I questioned myself and started thinking that it's not that I know C (I don't, after 20 years or so), but that I am very comfortable with it and I don't want to change that comfort. C++ and 90's traumas and post 90's (STL) traumas had a lot to do with it. Now, I'm fishing out for newer languages that would replace C for me, Rust namely, but I'm still falling back to C all the time. Now, I'm thinking that that's just the way it is. I'm a C programmer and that's how it will stay. At least for a long while. I do and have used a lot (A LOT) of languages in my past, but my core is always C (also first language I've learned). I don't program anymore for a living (I do "creative stuff" in film and tv now), so that is now more prominent than any other time in the past. I do stuff for me only and I can pick and choose whatever I want to - yet, it's always C.
This mirrors my experience. C is a drug man. It's bad but you can't stop. You know how to get shit done in C and it's easy to think in. C is, IMO, something of a local optima for programming. Problem is, it's actually a relatively awful language, and I don't subscribe to the worse-is-better philosophy (though C may well be the best example of it).
Thankfully Rust gets my ML instincts going. I'm trying to use it more. It'll be nice not to be anxiously running my test suite under ASAN after every build.
I am surprised you never found managing those risks as stimulating. I do. 'C' is pretty good at providing the furniture needed to enforce formal constraints.
Yeah but after sixty years of C, why should we trust an origanization like Mozilla? They've been thoroughly unwilling to come up with any sort of ANSI standard or anything, despite Rust being a reasonably mature language.
Google sought ECMA standardization when they took on Dart. Go language has an official specification, so someone could hypothetically re-implement it if they wanted to, and remain compatible Go projects.
Mozilla only wants Mozilla to be involved with Rust. They want everybody to use it in their systems, and have no input on where the language should go.
This comment is beyond uninformed. Rust is currently working towards standardization, starting with the memory model. See http://smallcultfollowing.com/babysteps/blog/2016/05/23/unsa... . This work is being undertaken by Niko Matsakis (a Mozilla employee, so yes, Mozilla cares about standardization) and Nicole Mazzuca (an independent volunteer, so yes, Rust takes broad input from the community).
As for "they want everybody to use it in their systems, and have no input on where the language should go", you appear to be utterly clueless about how Rust is developed. Enormous swaths of the language have been designed by contributors who just showed up out of the blue and started putting in elbow grease. Iterators. Every data structure in the stdlib. Crucial, fundamental details of how the borrow checker operates. There's an entire repository for allowing anyone to propose changes to the language (a process which Mozilla employees are also forced to follow), which is a model that several other open source projects have since adopted (e.g. Swift).
Really? The Rust community has been one of the most open and encouraging ones I've seen. They've also taken great pains to make sure that community feedback is solicited and incorporated.
From the little research I have done into Rust it seems unsurprising that there isn't a formal definition as any Rust standard would be similar in value to Haskell 2010. Useful but not sufficient due to the language still evolving.
All of the things which the C-like replacements for C are competely missing the point. All their goals can be achieved by using a decent high level language (not "C like"), together with using C for just those parts that have to run fast, or interact with the hardware.
"Let's make an improved C, and then write millions of codes in nothing but that" is a myopic non-starter.
How does this apply towards library creation, where the code is meant to be consumed by other programs languages?
While the total lines of code in libraries is less than that in applications, I would say the relative importance is more. That zlib has a fast and correct implementation matters to a lot of people.
That's right; one fast and correct zlib matters more than giving everyone an improved C so that they can all try to roll their own zlib that is fast and correct.
My comment was mean to point out that even if we magically achieved your dream tomorrow, and almost all applications were written in some HLL (which is probably a good thing), the amount of machine code being run in those applications that was generated from C is still substantial due to library use. If we accept that C is "bad", or at least that some major gains in usability, reasoning and security can be made by changing or replacing it, then there's still a major benefit to doing so.
When a bug comes out in zlib (or more likely, OpenSSL again), and we can attribute it to poor engineering in C, it doesn't really matter that all the applications are written in a HLL if they still loaded the library and used it because the performance was needed.
Interesting. I thought Microsoft has stopped liking C a while back. Remember complaining about C99 support in VS and getting a response about "Just use C++ compiler as a C compiler, you don't need C anymore". It took them until VS 2015 finally to support it.
Also the DDK (Windows Driver Development Kit) didn't support C++ in any meaningful way. If I remember correctly, all my drivers had to be written in C89.
The idea is nice (although old and tried more than once), but I'm pessimistic as it doesn't seem to be backwards compatible and requires a specific, new compiler. For legacy projects it's hard/impossible to change a toolchain/compiler and for the new projects one can as well use Rust or other modern language.
You should look at their paper. They have an impressive survey of prior approaches including Cyclone, and they claim that their approach (if I understand them correctly) could allow you to do some things outside of unsafe blocks if implemented in C# or Rust.
I don't see any use-after-free prevention here from a skim of the paper, so this doesn't seem to address many of the most important benefits you get from C# or Rust.
Use-after-free is not a theoretical problem. All of the Pwn2Own vulnerabilities this year were UAF, for example.
I can't upvote this enough. I started to play with Rust a few months ago and I especially like their compile-time checks of the code. I don't see why C compiler vendors can't do the same thing. Imagine if folks like GreenHills or WindRiver adopt such a practice in their compiler. It would revolutionise their industry. IAR has MISRA-C checks in their compilers but that is not enough.
There's already an industry providing static analyzers for C (Coverity, Klocwork, Polyspace, etc). If you're doing mission-critical C you're probably using these already.
the obvious question: how does this compare to rust? it looks like rust and this aim to solve a very similar set of issues in more or less similar way ('static and dynamic checking'). i'd be very interested in a table that compares capabilities of both. of course there's a gigantic advantage of this being C, so in theory valid checked C would be valid C with all benefits of that.
Well, this isn't C: it's a different language that extends C. There's a big difference between that and just being C. In particular, valid checked C is not valid C, because checking requires using the language extensions.
Regarding the comparison to Rust, Rust prevents use-after-free, while this doesn't seem to from a skim of the paper. Use after free is one of the most, if not the most, common remote code execution security issues in C and C++ code nowadays.
Before getting too excited and claiming that it's only 1.3% of all CVEs or something, remember that it's 1.3% of all vulnerabilities. (Especially with the explosion of dynamic web languages, a lot of CVEs aren't really C/C++-related.) There's a power law to these things, so by the power law metric, it's not that far behind "buffer overflow" (6,500 entries), and ahead of the well-known "format string" (577), which is also certainly "one of" the most common C issues.
I'm looking specifically for remote code execution vulnerabilities, which is what the original comment was discussing, and which is a subset of what you posted.
And no, this is not like asking for citations for the sky sometimes being cloudy because the original comment didn't say "use-after-free sometimes leads to remote code exploit".
This is like asking for citations for a claim like "whenever the skies are cloudy it is due to acid rain more than any other reason". And a claim like that should be accompanied with some citations.
Let's have an honest discussion here, or don't bother, please.
> It's representative of the state of the art in attacking large, mature, modern C++ codebases.
I would say it is representative of attacking client side desktop browser software and plugins. That seems quite a bit less representative of all C and C++ software, most notably excluding server-side software.
> I work in this space, you know.
That's why I was hoping for something more than "trust me" as a citation.
It is a design goal to allow Checked C to be a subset of C++ too.
Interesting. In times when many people advocate a safe C++ subset, Checked C grows the other way, adding C++-compatible notation to represent the most vital things like smart pointers.
Good timing for me, since I have been falling back to C for some personal projects. I keep looking at Rust, but I just don't have the time. It would be nice to leverage the experience I already have, and see what Checked C offers.
This greatly lacks an overview as the specification[1] is very in-depth.
I kind of wonder if they're working on automatic conversion tools between C and checked C.
At least for ptr<> this should be trivial. If a function does no pointer arithmetic with a * pointer and only uses it in function calls that take ptr<>, can be converted to a function taking a ptr<>.
Language extension for maintenance of legacy application sounds a little bullsh1t to me.
0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application.
1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors/exceptions (like overflows) would need handling and changes in logic. It could only deny read/write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).
One use case I see is to add an extension (like GCC's for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.
The phrase "couldn't be bothered" is assuming a lot of bad faith on Microsoft's part. While I would agree that in times past MS didn't deserve the benefit of the doubt, these days they're a different company.
With no special insight into their reasoning, I think the more likely answer to the question, "Why didn't they contribute this upstream?" is probably "Give it time."
We've banned this account for being a pro-Microsoft astroturfer who has plagued HN for years. This person (or persons) is an accomplished if not professional pro-Microsoft astroturfer whose "contributions" to Hacker News consist of shilling for Microsoft, slagging Microsoft competitors, and covering their tracks. They've made networks of accounts to reply to each other and create the false impression of conversation. At one point they even created fake female identities to make it look like when we banned them, we were banning women.
We ban any account that evidence suggests is part of this campaign or anything similar. Users who think they see signs of this are invited to email us at hn@ycombinator.com so we can investigate. Please don't level accusations of astroturfing at other users in threads, though. For every case like this one that really is astroturfing, there are dozens more of legit users simply holding divergent views. We don't want a culture of accusing others lightly.
I take it this is a matter of the mods having some access to information that I don't (given that this account is only 2 days old), but:
In this case, I think much of what this user posted sounds pretty reasonable. I'm not a Microsoft fanboy or anything, but all the vitriol Microsoft gets in light of all the love that Apple and Google get seems silly to me.
I think the concerns some people have that Microsoft will quickly return to their old ways are legitimate, but also a little on the paranoid side. That argument is contingent on Microsoft actually regaining their market position that they once had in the 90s and early 00s, which, frankly, I don't think will ever happen: most developers now flat-out expect that their development tools will be Freely-available ("Free as in Freedom", etc.); most end-users now expect that the "apps" they want will be available for free or at least very cheaply (with prices listed in cents rather than dollars) -- I've seen many comments in the Google Play store where users are complaining about the price of a $2 app, forget about $5 completely. Frankly, people simply aren't willing to pay for software anymore. Regardless of how you feel about that, it's obviously the case these days. As such, I don't think it's unfair to claim that "free software has won".
Furthermore, Microsoft seems to be catching a lot of flak for things that Apple and Google do on the regular, yet many are willing to overlook. I recall seeing a recent thread here on HN in which a user pointed out that Google's update practices are the same if not worse than the recent Windows 10 update fiasco. Yet, you don't see nearly as many people complaining about it.
Finally, it should be obvious that any for-profit business exists for the purpose of generating profit. Given that, it should be no wonder that a business's behavior will be driven by a motive of revenue. Especially in the case of publicly-traded companies, there has been a long history of business behavior motivated by shareholders' interests.
All that said, I have to trust that the HN moderators made the right decision here, but I honestly haven't seen this user make any claims in this particular thread that seem unreasonable. Yes, they are defending Microsoft in their comments, but sometimes I feel as though Microsoft actually needs defending in nerd-circles nowadays, simply because their checkered past makes many of us unwilling to accept that Microsoft may have actually made a change of face recently. Furthermore, is a pro-Microsoft shill really any worse than an anti-Microsoft shill? Going yet further, I've seen plenty of HN users who talk like pro-Apple shills, yet it seems that since so many around here agree with them, that's deemed acceptable.
Anyway, I just wanted to put in my 2¢. Thank you for all that you do to keep this place clean, even if I might not always agree on what constitutes cleanliness :)
Yes, in this case it's a matter of us having data that isn't public.
Although I don't agree that that account's comments in the thread were reasonable (they were highly uncivil, which is a bit of a new tactic for them), you can't judge this kind of abuse by the reasonableness of individual comments alone. This person or organization does professional-level dissumulation and manipulation of online discussions to deliver false impressions and corrupt the community. I rarely use such strong language (indeed I post far more comments asking users not to accuse each other of astroturfing). I do so in this case because they've done a lot of damage to HN over the years and because users need to know how seriously we take real abuse when we see it. Each time this person or organization shows up again, we crack down hard, and publicly. They should know that they're hurting Microsoft's reputation, not helping it.
Most MS-related comments on HN, though, are by legit users. The generalizations people constantly make about the HN community—in this case how it sees MS—are nearly always bogus, driven by cognitive bias, not data. I see a ton of people complaining that HN has gone to shit because it's full of Microsoft promoters [1] and an opposing ton of people complaining that it's full of Microsoft haters. The explanation is that the community is simply divided. Both sides can point to lots of comments that seem to support their favored generalization, but going from "I notice comments that rub me the wrong way" to "HN is full of shills posting against/for the things I like/dislike" is a non sequitur.
Thanks for the response. Now I know, and knowing is half the battle!
Every time I see people complaining about how "HN as gone to shit", I check to see how long they've been a registered user. I'm not the most veteran HNer, but I've been around for about 6 years now, and if anything I think the quality of the site has tended to improve ever-so-slightly over the years, though I feel that it tends to fluctuate a bit. There was also a noticeable boost when you and your crew took the reigns as mods (I don't mean to ass-kiss here, I really feel that way). I sometimes wonder if I missed out on some sort of Golden Age of HN...
Sometimes the profit motive incentivizes behavior that is bad for developers and consumers. Shareholders and executives made a lot of money from abusive behavior on Microsoft's behalf in the 90's. It can be argued that behavior wasn't ideal for profits in the long-run, hence their change in tactics. Unfortunately, there isn't much evidence that Microsoft won't return to those highly profitable methods once they're more competitive.
I've written lots of C and never had problems with buffer overruns, bounds checking, double frees, and other memory issues. Typically at a glance in one's code, I can tell when behavior may be undefined, and once someone has a little experience, they can avoid undefined behavior altogether. Why does so much work go into fixing these problems? In other words, what are some examples of use cases of a stricter language like this, that would be too complicated for human eyes to quickly verify?
> I've written lots of C and never had problems with buffer overruns, bounds checking, double frees, and other memory issues. Typically at a glance in one's code, I can tell when behavior may be undefined, and once someone has a little experience, they can avoid undefined behavior altogether. Why does so much work go into fixing these problems? In other words, what are some examples of use cases of a stricter language like this, that would be too complicated for human eyes to quickly verify?
Some memory issues with code you might be familiar with... From your own repo.
Not checking for return values is not a great idea. Your code blows up phenomenally with certain "width" and "height" values. It does check against negative grid sizes, but that's not enough (https://github.com/AndrewBelt/game_of_life/blob/master/src/g...)!
With suitable width & height it'd also gladly free a "grid" it never allocated. Of course it crashes long before that happens.
Ok, so it was cloned from someone else's repo, and you never got around cleaning it up.
There is also integer overflow: alloc is int, so if it becomes greater than 2^31-1, it may wrap around [I think signed int behaviour in C is undefined in this case], and you'll allocate fewer bytes than needed, leading to buffer overflow.
Well, to be honest, very few programs are able to orchestrate >2GB allocations correctly when complied to 32 bit binary, like Visual Studio linker is not aware of >2GB sizes by default (one need to /LARGEADDRESSAWARE flag for it), which was a trouble for modern browsers because linker was unable to fit everything in limited virtual address space.
And another to be honest, very few programs on desktops/mobile are actually checking return values of malloc/calloc, because of amount of data that program operates is usually much smaller than amount of RAM available. It's sure a case for embedded, but you simply usually don't use malloc for embedded.
A constant stream of memory-safety related vulnerabilities get found in popular C and C++ programs, many exploited in real attacks. If you haven't "had problems", then either you're far better than most experienced programmers, or you just haven't had many people examine your code with the explicit intent to cause problems. :)
> I've written lots of C and never had problems with buffer overruns
Well, if that is true, you are either very lucky or very brilliant. I have written moderate amounts of C, and I have run into those problems repeatedly.
Maybe that just means I am an idiot, but it appears that smarter people than me make such mistakes as well (although less frequently, I hope). C - at least when compared to most other popular languages - makes it very easy to make such mistakes.
> Why does so much work go into fixing these problems?
Because these problems have cost lots and lots of money thanks to crashing or misbehaving software (including many a security problem). Not to mention the sanity of the programmers who had to debug these...
(Also, I am told that in embedded/realtime software memory management is a lot simpler, as malloc/free are typically not used; you didn't say what kind of C code you have written, but if you are an embedded developer, that would at least partially explain your experience.)
The general idea is straightforward: "The unchecked C pointer type * is kept and three new checked pointer types are added: one for pointers that are never used in pointer arithmetic and do not need bounds checking (ptr), one for array pointer types that are involved in pointer arithmetic and need bounds checking (array ptr), and one for pointer types that carry their bounds with them dynamically (span)." So this is really a new language derived from C, to which programs can be converted.
This is basically a good idea, but it's only useful if pushed hard by somebody like Microsoft. People won't convert without heavy pressure.
[1] https://www.cs.virginia.edu/~weimer/p/p477-necula.pdf