Slashdot Mirror
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.""
The Cyclone compiler will rewrite the code or suggest fixes to avoid potential bugs
I don't mind suggestions, but I'm not sure I like the idea of having my code rewritten.
Couldn't the same error-checking be incorporated into a pre-processor rather than developing an entirely new compiler/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.
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.
UNIX *is* user-friendly. Its just more selective on who its friends are. --Scott Adams
Here it is from the User's Manual
There are other safe programming languages, including Java, ML, and Scheme. Cyclone is novel because its syntax, types, and semantics are based closely on C. This makes it easier to interface Cyclone with legacy C code, or port C programs to Cyclone. And writing a new program in Cyclone ``feels'' like programming in C: Cyclone tries to give programmers the same control over data representations, memory management, and performance that C has.
There is a whole host of languages more "modern" than C, Java, C++, C#, Pascal, Ada, Perl, or any other of the essentially von Neumann-style languages out there. I highly recommend that anyone out there who is interested in advanced type-safe languages take a look at SML, O'Caml, Haskell or Clean. Most of these languages have more or less formalized language semantics (as in mathematically precise). Formal descriptions and strong type systems allow the compiler to *prove* (again, in a mathematically precise sense) that a program can not go wrong at run time.
Benjamin
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.
A quick summary for everyone who hasn't taken or has forgotten their TheoComp: An NP problem: one that can be solved non-deterministically in polynomial time (NP=Nondeterministic polynomial). Therefore it can be solved deterministically in exponential time. An NP-complete problem: If any NP-complete problem can be solved in polynomial time, every NP-complete problem can be solved in polynomial time. An NP-hard problem: If any NP-hard problem can be solved in polynomial time all NP-complete problems can be solved in polynomial time, but not (necessarily) vice-versa. Undecidable: The problem can not be solved deterministically in finite time. NP-(hard/complete) problems are ususually solved by approximation or brute force. Or by restricting the problem--Euclidean travelling salesman can be solved in polynomial time. Undecidable problems are usually approached by restricting the problem--Halting, for instance, can be solved if you bound the number of states. Getting back to the original topic, that's what languages try to do. By restricting the operations you can perform, they can make garuntees like "These two variables will never reference the same area of memory"
I have worked in an ADA shop for 4 months. I started out by being very positive towards ADA - being told that "in ADA you write a little more than in C, but basically you just write what you mean".
Then why is an array written in the same way as a function call? Without [] I have to write:
i(j) -- i is the function which returns bla
x(j) -- x is a table lookup which is used for bla
I don't get it.
An ADA compiler writer told me that also made it much harder to make the ADA compiler.
I quit the job and is now back doing C.
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.
Take a look... it basically is Ada, redone with C syntax and without the built in tasking niftiness.
[Ada => Cyclone]
type checking => type checking
exceptions => exceptions
discriminated types => tagged unions
parameterized types => polymorphic data structures
access types => * pointers
polymorphism => polymorphic functions
private sections in package spec => abstract types
array slices => subtypes
Ada has a lot more features, the only ones Cyclone boasts over Ada are: garbage collection as the norm not the exception, and tuples.