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.""

Comments

Just what I need...

[mshomphe]

buggy code to tell me when my code is buggy.

I am against this

[Anonymous Coward]

C is *supposed* to be dangerous, damnit.

No No No

[VFVTHUNTER]

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)?

Re:Isn't that called "Java"?

[The_egghead]

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.

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

[Tsar]

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.

Lclint

[Ed Avis]

A lot of the static checking made possible by Cyclone can be done for ordinary C with lclint, 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++.

New language?

[LinuxDeckard]

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.

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.

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

[Embedded Geek]

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. 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

[jdfekete]

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.