C with Safety - Cyclone

Paul Smith writes: "New Scientist is carrying a story about a redesigned version of the programming language C called Cyclone from AT&T labs. "The Cyclone compiler identifies segments of code that could eventually cause such problems using a "type-checking engine". This does not just look for specific strings of code, but analyses the code's purpose and singles out conflicts known to be potentially dangerous.""

Isn't that called "Java"?

Not a flame, but more "modern" languages such as Java and C# have constructs explicitly built to avoid the buffer overflow/pointer gone insane problems.
For the rest of the world, secure C programing [google.com] is far from a secret.

Re:Isn't that called "Java"?

There's a key difference here though. Java requires a run-time stack to do all of it's safety checking. This project aims to all of it's checking at compile time, so it's static, rather than dynamic. This is _VERY_ hard problem, and is where virtually all of the programming languages research is centered today. However, you're instinct that this is not a new concept is correct. Microsoft is actually doing very similar research in the form of a project called Vault [microsoft.com].

Lclint

A lot of the static checking made possible by Cyclone can be done for ordinary C with lclint [virginia.edu], which lets you add annotations to C source code to express things like 'this pointer may not be null', 'this is the only pointer to the object' and so on. You write these assertions as special comments, for example /*@notnull@*/. These are checked by lclint but (of course) ignored by a C compiler so you compile as normal. (If you weaken the checking done, lclint can also act as a traditional 'lint' program.)

Also C++ provides a lot of the Cyclone features, not all of them, but it certainly has a stronger type system than C. I'd like to see something which combines all three: an lclint-type program that lets you annotate C++ code to provide the extra checks that Cyclone (and lclint) have over C++.

Just what I need...

buggy code to tell me when my code is buggy.

I am against this

C is *supposed* to be dangerous, damnit.

No No No

We had C, then C++, then C#. So shouldn't the next logical step be C followed by three vertical lines and three horizontal lines (that'd be C-tic-tac-toe)?

"C with safety," or C with trigger locks?

I like the notion of building protection against common, insidious errors, but why did they have to create a new language to accomplish it? I didn't quite understand that point.

And isn't a cyclone an infinite loop?

"Our ultimate goal is to have something as humongous as the Linux operating system built in Cyclone," says Morrisett.

You have to like a scientist who uses the word humongous.

party like its (Simula) 1962

Someone created a language the enforces types and does bounds checking! It's news!

The wrong starting point?

I'm a professional software developer, and all for anything that makes my code safer without unduly compromising it. But I can't help thinking that starting from C is probably a mistake.

C is a fundamentally unsafe language. It has some easy fixes (remove the always-unsafe gets() function from the library, for example). It has some fundamental "flaws" (pointer arithmetic and the use of void*, for example). I quoted "flaws" because, while these features make the language necessarily unsafe, they are also very helpful in the low-level programming that got C to where it is today.

The underlying problem here has never been with C, it's been with using C for the wrong jobs. Application code, and certainly high-level code where security is essential, just aren't C's strong suits. I can't see how even the geniuses we're talking about can start from such a broken language (in the context we're discussing) and successfully make a non-broken language out of it.

I would expect a much better solution to be that followed by later C-like languages. C++ retains the low-level control, but other languages (Java, C#, etc) are available to those willing to sacrifice some of that control in exchange for added safety, and consequently may be better tools for different types of project. The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++. As they evolve, and catch up on the 20-odd year head start, hopefully we'll see programmers given a genuine choice between "safe but somewhat limited" and "somewhat safe but unlimited".

Re:The wrong starting point?

> The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++.

Take a look at Ada [adapower.com]. Extremely safe, extremely powerful, extremely unpopular. Go figure.

It's object-oriented, it supports generic classes ("packages", in Ada terminology), it has built-in support for multitasking and distributed programming, it lets you (optionally) specify even such details as numeric representations for the ultimate in portability, and it has a set of first-class and well-documented bindings for GTK+ [act-europe.fr].

There's a free compiler called GNAT, which is built on gcc and will actually be rolled in to gcc 3.1 or thereabouts. There's also a Linux-specific [gnuada.org] site for gathering and distributing component packages.

And pace ESR, it wasn't designed by a committee.

Vision of the future

The Cyclone compiler will rewrite the code or suggest fixes to avoid potential bugs. Even if a bug still occurs, the compiled system will lead the program to halt safely, not crash.

Am I the only one to whom this sounds like potentially a really bad idea? I mean, think about it, coding along one day:

#include

int main() {
printf("He

At this point, small, cute cartoon versions of Kernighan and Ritchie pop onto the screen and say "It looks like you're writing a Hello World program! Click here to check this program for bugs automatically..."

I'm just shuddering at the thought...

New language?

I always let out a bit of a grumble when a new programming language comes out; they seldom add anything truly new to programming. When I read that Cyclone was strikingly similar to C, I was intrigued enough to skim through the docs [http].

Put bluntly, Cyclone seems to be little more than C for lazy programmers. Fat pointers for those who can't follow the logic of pointer arithmetic and *`H for those intimidated by malloc() is not a beneficial service.

Safety in C and C++

Cyclone is a long way from C. It requires garbage collection, has exceptions, and quite a bit of new syntax. Bell Labs has generated quite a few C derivatives. C++ is the only one to catch on, but Cyclone is at least the fifth C derivative to come from There was also C+@ (a Smalltalk-like variant) and two others previously discussed on Slashdot.

I'd like to see Cyclone's kind of safety, but if you're going to require garbage collection and forbid pointer arithmetic, you may as well use Java.

I've proposed "Strict Mode" for C++ [animats.com], a compatible retrofit to C++ that uses reference counts like Perl, but with some optimizations to get the overhead down.

A basic decision is whether to have garbage collection. If you have garbage collection, C++ destructors don't fit well. (Java finalizers, called late, during garbage collection, can't be used for things like closing files and windows. Microsoft's C' has destructors, but the semantics are confusing and ugly, and we don't have much mileage yet on how well that will work.)

Reference counts work reasonably well. There's a problem with not releasing circular structures, but that doesn't keep Perl from being useful. Perl now has "weak" pointers (they won't keep something around, and turn to null when their target goes away), and if you use weak pointers for back pointers, most of the circularity problem goes away. True rings of peer objects are rare, and they're the main case where weak pointers won't solve the problem.

If you don't have garbage collection or reference counts, programs obsess on who owns what. A basic problem of C and C++ is that it's essential to track who owns which objects and when they're supposed to be released, yet the language offers no help whatsoever in doing so. This is the fundamental cause of most crashes in C and C++ programs. Almost every core dump, "bus error", or "general protection fault" comes from that problem. So it's worth fixing.

It's the right time to address this. We're in a period of consolidation, now that the dot-com boom has collapsed. Our task as programmers over the next few years is to make all the stuff that sort of works now work 100%.

Legacy Savior? A culture fix would be better...

In my shop, we do everything on a shoestring, kludging together tons of C legacy code from multiple generations of our products. We take an application that ran on a homebrewed executive and stick it on an RTOS, spoofing it so it doesn't know the difference. We grab code written on an 8 bit microcontroller and port it to our 32 bit x86 with minimal testing. Given all this, my first thought at reading the article was to raise three cheers. The idea of making a system already written a lot safer... I can hardly find the words.

Then I got chewing on it and realized something: when I came on board and suggested running lint on our code, I was shot down by both the rank & file and by management (who each blamed the other). When I suggested a concerted effort to rewrite our code to eliminate or justify (in comments) every warning our compiler spewed on a build, I got a similar reaction.

Don't get me wrong. I think cyclone still sounds great, especially the pattern matching and polymorphism indicated on its home site [cornell.edu]. If it can gain some momentum, it stands to have a real place (niche?) in dealing with legacy systems. For my shop, though, I fear much of the value would be wasted. Until we change our motto from "There's never time to do it right, but always time to do it over" we're going to continue repeating our mistakes.

Static verification vs. type-safe languages

Hi,

In 1999, the Ariane 5 launcher exploded a few seconds after leaving the ground. The faulty program, written in type-safe Ada, has been submited to a static program analyzer developped by Alain Deutsch at INRIA in France. The analyzer spotted the error right away!
It was a number going out of range after too many iterations and wrapping back to 0.

The verification technique used was based on abstract interpretation.
This is just to say that even a strongly type-checked language can fail and that type checks, whether static or dynamic, are not the only way to catch bugs.

Alain Deutsch has started a company called Polyspace that sells static verifiers for Ada and C (See www.polyspace.com). The idea is not to rewrite C or Ada but to spot potential bugs inside programs.
I have no special interest in this company, (I know Alain Deutsch), but I mean that improving C does not imply removing the type-unsafe onstructs.

C with safety. reminds me of a story...

Back in the days when "speed" meant catching a train with a full head of steam, railroad repair engineers were a brave bunch, and many sported stumps of arms and legs as mute witness to their bravery in repairing moving trains.

One day, a city slicker with a spotless seersucker suit and a perfectly pointy moustache was reported travelling from station to station, selling his new technology suite. It included remote manipulators for making repairs from a higher level, without having to go under the trains. It also came equipped with "parking brakes" for trains, to prevent them accidentally moving while they were under repair.

This new "high level" technology was a hit in many towns, where the young repair technicians were unenthusiastic about life with missing limbs. In addition, the new technology came with many interlocking "safeguard" mechanisms to make sure that no fittings were left unsecured when the repair was completed. This saved many a "crash".

But there remained many towns with older engineers, who had grown up doing things the "fast" way, repairing the trains on the fly (because things went faster that way!), and of course having the scars and stumps to show for it. They were also unenthusiastic about the "safeguards", declaring that they were "smarter than any newfangled machine", and could remember to close the latches and fittings themselves.

In one of these Ancient Telegraph Towns, one of the older engineers, Cyclone Bob, came up with his answer to the newfangled "high-level machines" -- special steel braces to wear over arms and legs while repairing the moving trains. "In most every case, these braces will protect your precious limbs from the hazards of moving wheels!", enthused Cyclone Bob.

The older engineers, who, when all was said and done, actually enjoyed mucking about under trains, and who had already paid their dues in missing limbs, were rather proud of the new braces, and wore them proudly. "My trains hardly ever crash now", they would say, "and now I don't always have to lose a leg to prove it!".

The younger, smarter engineers continued using their "high-level" machines, and were happy that they still had arms so they could snigger up their sleeves.

disappointing speed, too complex

I pulled it over and installed it. Running their own benchmarks, it seems 5-10x slower than C on most benchmarks. Also, looking more at the documentation, this is not merely a "safe version of C", it's a pretty complex language with C-like syntax but many ML-style features.

Cyclone could be a winner if it gave you C-like performance with safety and minimal changes to your programs. But it doesn't match C performance as it is and I don't think large, existing C programs will port to it easily, despite superficial similarities.

The way it is, I think you are better off using O'CAML [ocaml.org] or MLton [clairv.com]. They are probably easier to learn and give you better performance. O'CAML, in particular, has already been used for a number of UNIX/Linux utilities. And Java is probably as C-like as Cyclone and runs faster (although programs have a bigger footprint).