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

Re:Pre-processor better??

[Bob McCown]

I don't mind suggestions, but I'm not sure I like the idea of having my code rewritten.

In the early 90's, we were using one of the C compilers at the time (dont remember which, sorry, we quickly dumped it when Borland came out) one of the error messages was "Need semicolon here" with a ^ to show where. My reaction, every time, was "Shit howdy, if you know that, put it in, and make it a warning!"

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.

Smarter than the compiler?

[iBod]

i program in C because i'm smarter than the compiler

Well, that's not too difficult. Compilers are just a bunch of algorythms.

Question is - are you smarter than the person that wrote the compiler?

Re:Isn't that called "Java"?

[roca]

You are wrong.

Java does not rely on a "run time stack" for its type checking, whatever that means. Java does plenty of checks at compile time (and load time, if you're using dynamic loading/linking).

Java, like Cyclone, Vault and every other language you'd ever want to use (and many you wouldn't), relies on a combination of static and dynamic checks to ensure safety. Cyclone does move more checks over to the static side than Java does, so it might get higher performance. But no compiler, and certainly not Cyclone's, will be able to eliminate all dynamic checks (for array bounds and null pointers, for example). Vault moves even more over than Cyclone.

There is a spectrum that describes the amount of dynamic checks that have to be performed for safe execution of a language. It looks a bit like this:
Vault ... ML ... Cyclone ... Java ... Perl ... Scheme

(C and C++ aren't on there because they don't have any concept of "safe execution" :-).)

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.

Re:Isn't that called "Java"?

[patniemeyer]

This is a misconception - The only runtime phenomenon that Java requires is array bounds checking. Everything else - including all of its safety rules are performed in a static verification pass. This is what allows Java to be "jit'd" to native code and run at full speed.

However because Java has so much more structure by virtue of the intermediate byte code language a runtime profiler can dynamically optimize sections of code based on their behavior, not just their static characteristics.

Ask yourself - what can I do at compile time that I can't do better with more information at runtime? The answer is nothing... The only trade off is in start up performance and it's just a matter of time before the OSs handle that better.

Pat Niemeyer,
Author of Learning Java, O'Reilly & Associates

let's fix the org before fixing the lang

[iskander]

``The underlying problem here has never been with C, it's been with using C for the wrong jobs. [...] The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++.''

You seem to have assumed, for the purpose of the above exposition, that implementation languages are chosen by well-informed people, and substantially on the basis of technical merit. That's not always the case. Well, outside your shop in any case. ;-)

In my opinion, acceptably safe languages that are quite expressive do already exist. I do not believe that the alleged deficiencies of safe languages explains the continued use of "unsafe" languages in domains for which the latter are not a good fit; I believe that, on the average, ill-conceived implementation strategies are more likely at fault. How many projects struggle with inadequate languages as a result of misinformed (or even uninformed) managers' inconsiderate (and uncontestable) decrees? Too many. :-(

I am happy to learn that smart people are busy inventing the next great programming language, but I think that, collectively, we need to spend less time improving our tools and more time addressing the organizational deficiencies that result in our having to use the wrong tools when we know better.

Too Bad

[gaudior]

If you are using ANY modern compiler, targetted for a modern CPU, your code is getting re-written without you knowing about it. It's getting re-arranged for pipeline efficiency, loops are getting unrolled, common sub-expressions are getting stripped. The notion held by some C programmers that they are smarter than the compiler is quite silly.

I am not sure of the usefulness of this particular language/compiler/etc, but I like the direction they are going. DWIM(Do What I Mean) programming is becoming more and more possible, with this kind of language research. We want programmers to solve problems in the macro world, not be bothered with the minutia of the language they are using. This has been one of the appeals of perl over the years.

In defense of type systems

[Tom7]

I think you must have had bad experiences with safe languages (Java?). Static checking doesn't result in slowness (in fact, it can make compiled code faster in many cases, for instance by enabling alias analysis).

Static typing and safety also allow for *more* power than a "do anything you like" language. One kind of power I get when I write in a language like this is the ability to enforce invariants without runtime checks. So if I am writing a program with several other people (or by myself across several evenings, except I am drunk some of those evenings), I can arrange my code such that bugs in one part of the program can NEVER affect other parts of the program. Thus, it is easier to figure out who to blame and where the bug is. This is impossible in a language like C, where any code can write over another module's memory, free its data structures more than once, or cast, etc.

Speeding up routines with hacks is pretty overrated; there are very few places where this is necessary, and even fewer where it is desirable. In those cases, we can always fall back to C or assembly.

Re:Pre-processor better??

[gorilla]

If you're using an optimizing compiler, then your code is being rewritten. Unrolling loops, storing of computed values, register assignment etc.

disappointing speed, too complex

[mj6798]

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 or MLton. 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).