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

Safety in C and C++

[Animats]

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

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

Re:The wrong starting point?

[Black Parrot]

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

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 site for gathering and distributing component packages.

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