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

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.

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.

Re:Safety in C and C++

[elflord]

Reference counts work reasonably well. There's a problem with not releasing circular structures, but that doesn't keep Perl from being useful.

It doesn't prevent perl from being useful, but no language which uses reference counts is ever going to replace C or C++. The problem with reference counts is that sometimes they cause more problems than they solve. A good example is in GUI programs, where a lot of objects might be mutually aware of each other. That's not to say that reference counts are not useful. Rather, forcing programmers to use reference counting to manage memory whether appropriate or not is problematic.

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.

C++ givas the programmer the flexibility to choose a memory management strategy that suits the problem at hand. Sometimes pool allocation works. Sometimes reference counting works. Sometimes, parent/child management works. It's very simple to implement reference counted classes in C++. It's certainly not necessary to exclusively use an "exclusive ownership" model in C++.

Almost every core dump, "bus error", or "general protection fault" comes from that problem.

They come down to a lot of problems -- library incompatibilities, bounds errors, and other things can cause these problems. I think it's naive to assume that using reference counting for everything will just make the problem "go away". Writing reference counted code without memory leaks gets quite difficult when the data structures are more complex.

The URL you have is interesting, and I think for some types of problems, using an object system where you just reference count everything is probably a good idea. But I question its value as a cure-all.