C with Safety - Cyclone 392
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.""
In related news.... (Score:2)
wasn't this supposed to be an NP-Complete problem?
Re:In related news.... (Score:2, Informative)
Back in grad school, I used to read comp.theory, and at least once a month, we'd have some jerk post to the newsgroup "NP solved!", followed by some stupid, exponential time algorithm for 3-SAT or something. Invariably, the poster would spend thousands of lines defending his supreme genius in being the person who solved an NP complete problem!
NP complete does not mean unsolvable. It means slow.
Roughly speaking, NP problems are problems for which their is no non-exponential time solution known, but for which solutions can be tested for correctness in polynomial time. (To translate, exponential time means that the time to compute the solution for a problem of size n is bounded by x^n for some n. Polynomial time means that the time for a problem of size n can be bounded by some polynomial of n.)
The travelling salesman is a classic example of an NP problem. Given a set of cities, and the distance between any two cities, compute the shortest route that visits each city once. It's a trivial problem, but as far as anyone knows, it's not possible to write a program that quickly determines the correct shortest route in every case.
NP complete problems are problems which have the fascinating problem that *if* you found a polynomial time solution for that problem, then you would have found a polynomial time solution for all NP problems.
The travelling salesman is, if I recall correctly, slightly *worse* than NP complete. Again, if I recall correctly, if you have a P-time solution to the TSP, then you provably have a P-time solution to any NP-complete problem; but if you have a P-time solution for an NP-complete problem, that doesn't mean that you have a P-time solution to the TSP. The proof is actually quite interesting, so go get an algorithm textbook, and read it. I'd suggest the Corman, Leiserson and Rivest text [fatbrain.com], which is my personal favorite.
There are perfect, well known solutions for all of the classic NP complete problems. They're just exponential time. (For instance, for the travelling salesman: enumerate all possible routes; compute the length of each route; and pick the shortest one.)
Re:In related news.... (Score:2, Informative)
TSP cannot be worse than NP-complete, because it is obviously in NP. Phrased as a decision problem (is there a Hamilton path through this graph shorter than length y?) it is trivial to verify a solution in polynomial time. If you can verify in P, you can solve in NP.
Note that rephrasing as a decision problem doesn't change the order much, because you can just do a binary search with O(log N) steps where each is a decision subproblem. Also note that transforming it into a decision problem is *necessary* to discuss its NP-completeness, because the very concept is only defined for decision problems.
Re:In related news.... (Score:2)
Dang, now I'm unsure if the Halting problem is NP-Complete.
Re:In related news.... (Score:2, Interesting)
Isn't that called "Java"? (Score:4, Informative)
For the rest of the world, secure C programing [google.com] is far from a secret.
Re:Isn't that called "Java"? (Score:5, Informative)
No, it's called "Pascal"! :-P (Score:2)
Seriously, modern Pascal compilers like Delphi/Kylix are capable of some compile-time checking...Pascal already has strict var type checking, and all you have to do is make sure its turned on when you compile.
This also includes bounds checking for arrays. Pointers are handled better than most C compilers, too.
The key difference here is that it sounds as if Cyclone checks the code for *intent* rather than just checking the types and such. That IS a hard problem.
Re:Isn't that called "Java"? (Score:3, Insightful)
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
(C and C++ aren't on there because they don't have any concept of "safe execution"
Re:Isn't that called "Java"? (Score:2)
Re:Isn't that called "Java"? (Score:2, Insightful)
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
A fancy way of saying "guess" (Score:2)
I'm sure you solve the halting problem for any application within 4 standard deviations without waiting too long.
While I agree with most of your post, I have to point out that coming within a factor of two is not very impressive for the halting problem. Since a given program on a given input will in fact either halt in finite time or it won't, your statement boils down to the assertion that it is possible to say either the word "true" or the word "false" (at random) in polynomial time. If you do this, you will either be right-within-a-factor-of-two (what most people would call wrong) or you will be exactly right. In the industry, this algorithm is called "guessing" and can be proven to be within a factor of two of correct on all binary choices.
-- MarkusQ
except Java doesn't have (Score:3, Informative)
(right on the web page detailing the language)
Actually Java does have (Score:2, Informative)
the 1.4 jdk (currently in beta) has pattern matching
parametric polymorphism (iow - templates) are in development and being called generics
Re:Actually Java does have (Score:2)
how many times do I have to say it? (Score:3, Informative)
Please read what pattern matching means when Safe-C (and ML and Prolog and Erlang and...) says "pattern matching" before you post your irrelevant link anymore.
Re:how many times do I have to say it? (Score:2)
Re:how many times do I have to say it? (Score:2)
The feature they are talking about has nothing to do with matching strings, but matching data structures. It is NOT REGULAR EXPRESSION PATTERN MATCHING. That is something different.
Re:how many times do I have to say it? (Score:2)
when people say pattern matching, most think of regexp pattern matching. it's what perl (and some other languages) is known and famous for.
datastruct pattern matching is something that's used a LOT less often (and something I have seen little about in my many years, of course I've never done functional languages)
so that's why people will think of perl-like regexps when people talk about pattern matching
Re:how many times do I have to say it? (Score:2)
Re:Actually Java does have (Score:2)
Re:Pattern Matching in java? (Score:2)
Not the Same Pattern Matching! (Score:2)
haha... oh.
Regular Expression matching is not the kind of pattern matching they mean here. Check out the language docs or a language like ML that has datatypes and pattern matching to see what they mean.
Re:Not the Same Pattern Matching! (Score:2)
regexps are used to describe the pattern you wish to match. hence i see both as pretty much the same thing because they go hand-in-hand.
Re:except Java doesn't have (Score:2, Informative)
> * Tagged unions
> yes, because it makes programs latently
> unrobust. Place a pointer and a double on the
> same adress and you never realy know where the
> pointer points to. Java just don't likes that,
> so it does not have unions.
You obviously have no clue what tagged unions mean. Thay are *tagged* which means that you can
tell which variety of union you have so it is
perfectly safe to use, e.g., in pattern matching.
Re:except Java doesn't have (Score:2)
I dunno man, when I write java code I really do miss pattern matching and generics. Casts and "instanceof" are a real pain.
Lclint (Score:5, Informative)
A lot of the static checking made possible by Cyclone can be done for ordinary C with lclint [virginia.edu], 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++.
Re:Isn't that called "Java"? (Score:2, Interesting)
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.
No, Java is for writing applications (Score:2, Flamebait)
Of course, if you're still writing applications in c, you're just asking for it. Cyclone might help, but you probably have other issues anyway.
better yet, get away from von Neumann (Score:2, Interesting)
Benjamin
Just what I need... (Score:5, Funny)
I am against this (Score:5, Funny)
Re:I am against this (Score:2)
in C you can access memory
and so you have to to write to hardware mmaped locations to control devices
how do you think low level manimpulation of devices is done in java/scheme
the point is they use very little and it provides a generic functionality its easy to audit and keep clean of bugs
so kludgeing stuff to make things typesafe seems to me at least silly
but remember Wickedness is a myth invented by good people to account for the curious attractiveness of others
regards
john jones
Just add wrapper libraries (Score:2)
Re:Just add wrapper libraries (Score:2)
I don't know about you but PhDs at IBM invented CD software that almost nobody can use and other PhDs have done many other totally impractical or redundant things with their time as well.
Just because you're good at doing research and writing long papers (which I've proof-read on occasion for people) doesn't mean you're good at coming up with unique or necessary solutions.
The fact that dmalloc and other such tools already handle the memory issues in some ways, or that other C library extensions are available to do memory segmenting differently at the malloc/free level is irrelevant to you? The fact that adding two lines to all the string.h functions that don't check for NULLs is stupidly simple doesn't make half their announcement redundant?
Sorry then
... slash drone
No No No (Score:5, Funny)
"C with safety," or C with trigger locks? (Score:5, Funny)
And isn't a cyclone an infinite loop? You have to like a scientist who uses the word humongous.
Re:"C with safety," or C with trigger locks? (Score:3, Informative)
Ever had an agressive optimizer break code, such that you had to use a lower optimization setting? This can be a symptom of weakness in the compiler's ability to statically analyze the program. Not just a garden variety "bug", but rather the optimization is correct only for a subset of valid input source code! I.e. it can be difficult to impossible to prove that a given optimization is safe, aka "semantics preserving".
Many modern PL researcher/designers thus aim to give compiler writers a head start by ensuring that the language design permits increasingly powerful forms of static program analysis. Functional language work in particular has focused heavily on utilizing language and type system design to enable more powerful analysis support. (cf. the various published papers on the Haskell and OCaml languages as a starting point).
party like its (Simula) 1962 (Score:3, Funny)
The wrong starting point? (Score:4, Troll)
I'm a professional software developer, and all for anything that makes my code safer without unduly compromising it. But I can't help thinking that starting from C is probably a mistake.
C is a fundamentally unsafe language. It has some easy fixes (remove the always-unsafe gets() function from the library, for example). It has some fundamental "flaws" (pointer arithmetic and the use of void*, for example). I quoted "flaws" because, while these features make the language necessarily unsafe, they are also very helpful in the low-level programming that got C to where it is today.
The underlying problem here has never been with C, it's been with using C for the wrong jobs. Application code, and certainly high-level code where security is essential, just aren't C's strong suits. I can't see how even the geniuses we're talking about can start from such a broken language (in the context we're discussing) and successfully make a non-broken language out of it.
I would expect a much better solution to be that followed by later C-like languages. C++ retains the low-level control, but other languages (Java, C#, etc) are available to those willing to sacrifice some of that control in exchange for added safety, and consequently may be better tools for different types of project. The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++. As they evolve, and catch up on the 20-odd year head start, hopefully we'll see programmers given a genuine choice between "safe but somewhat limited" and "somewhat safe but unlimited".
Re:The wrong starting point? (Score:4, Insightful)
Take a look at Ada [adapower.com]. 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+ [act-europe.fr].
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 [gnuada.org] site for gathering and distributing component packages.
And pace ESR, it wasn't designed by a committee.
Re:The wrong starting point? (Score:2)
> Now, when my employer sends me to classes on C++/java/etc., my most frequent comment in class is "Oh, that's like (blank) in Ada," which usually gets me strange looks from my classmates (and instructors).
Yes, it looks like C --> C++ --> Java --> C# is on a trajectory that is converging toward Ada. Oldtimers grouse that some of the things people rave about in Java are the same things people used to whinge about in Ada, back before Illuvatar changed the world.
> OT, but I think its unpoularity stems from the fact it was designed for DoD use, who then made it MANDATORY for all new projects.
You may be right. Interestingly, now that the DoD is letting it wither it is actually expanding its market a bit, particularly in Europe. (Or so I understand.)
Re:The wrong starting point? (Score:2, Interesting)
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.
Re:The wrong starting point? (Score:2)
> 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".
More on this further below.
> Then why is an array written in the same way as a function call?
I would also like to have brackets for the array indices, and have even considered writing my own preprocessor to allow that and some other syntactic sugar. But don't confuse a language's choice of syntactic structures with "not saying what you mean". If you want to "say what you mean", you have to do it in the syntax provided by the language in question. None of the syntax for any language "means" anything at all, except by the conventions established by the language specification. So if you do write something in language X, don't assume that the syntax should "mean" what it does in language Y.
> An ADA compiler writer told me that also made it much harder to make the ADA compiler.
That's a rather curious claim. All you have to do is look up the identifier in a table (which you have to do anyway, in any language) and have a peek at its properties (which you have to do anyway, in any type-safe language), and then spill some code depending on what you have found.
The static type-checking and overloading capabilities of Ada will make the compiler more challenging to write than some other compilers would be, but the difference between "(" and "[" is trivial for a parser. (Heck, some implementations of Scheme even let you use them interchangably.)
But back to the "basically you just write what you mean". I say the same thing, almost, but I mean it much differently than your interloqutor apparently did. I phrase it something like -Notice that I left out the word "just". Saying what you mean is a very demanding requirement, and those of us who haven't been through a software engineering program don't take to the requirement too kindly. We'd rather slop together whatever our language of choice allows us to get away with, and pay the price for it later if we're so unfortunate to still be around when the bug reports start coming in.
By analogy, the difference between "saying what you mean" and the way we program when we can get away with it is like the difference, for mathematicians, between a proof and a proof sketch. One is formal and rigorous; the other makes a convincing show, but might not actually be correct.
But its a very sensible requirement if you have safety in mind. And if you bite the bullet and get used to doing it in a "safe" language that expects is, you'll start reaping rewards for it. The whole point of using a language like Ada is, IMO, that it moves bug-catching earlier in the product's life cycle. The GNAT compiler will catch a lot of things at compile time that most other languages will "catch" by blowing up at run time. And it will catch other things by raising an exception at run time when most other languages would not catch them at all, leaving them to be caught by humans noticing that the program isn't producing the expected results.
Don't get me wrong; Ada (or any other langage, past or future) isn't a magic bullet that's going to kill all the world's software bugs. But it is a language designed for software engineering, and if you have the patience to learn to "say what you mean" they you'll spend way less time chasing bugs, and the time you do spend on debugging will almost always be a matter of making sure your higher-level algorithm is correct.
let's fix the org before fixing the lang (Score:2, Insightful)
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.
Ada experience / gnu Ada? (Score:2)
I didn't like it at first. Now I find I'm liking it more and more. It does a lot that make it really usefull in the "very very high" reliability programing.
It does have very strong type checking al la jave. You can make you own range constraints on types you create
If you try to make Y bigger or smaller that that range you throw a contraint exception
You pay a little in performance for this, but although I hear that if you did all that checking manually in another language it would be even slower.
It has some other nice features that other programming languages have in various forms, including enumeration types , records types (like a struct) and you can specify down to the bit level the arrangement of the struct..ie which fields go where. It even has "packages" which are a bit like objects.
Ada isn't as powerful as C though and it lacks a lot of the tools and libraries . Its also hard to find good books on it too.
One joke at work is that Ada actually more powerfull because you can bind it to C code.
We hear stories about other projects having problems with C and bigger problems with C++. Ada although slow to program in does nice for systems that require very high reliability.
There is a Gnatt compiler which is free and open source too... Try it.
Re:The wrong starting point? (Score:2)
You make my point for me, I think. As long as we insist on sticking to basing new things on what is currently popular, instead of what is currently good for the task in question, we will be hampered.
This is the fundamental problem with things like C#. C++ is still the most powerful language on the block in that family. Java provides a similar language for those who prefer that extra level of safety and don't need the low-level power. The market is saturated at that point; there is no room for a third contender in the middleground. I don't think anyone will ever produce a language in that family that is genuinely significantly better than either C++ or Java for any given job.
I know it's hard to get people to take up a new language, and hard to develop a new language without popular support. No doubt C++ wouldn't be where it is today if it hadn't been based on C, and yet now the C heritage is behind most of the biggest flaws in C++. What we need is to educate people enough to break this paradox, not to come up with ever more "slightly better" languages.
Cyclone Beta Testing (Score:2, Funny)
Either method is an enormous amount of overhead being generated by Cyclone. However, one can see that the amount of lines of code released in a release (by creating overflows) that actually goes to maintaining the Cyclone System spiraling bugs is a huge ratio of 400 to 1.
Stick with C++ I think.
Pre-processor better?? (Score:2, Interesting)
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?
Re:Pre-processor better?? (Score:2, Insightful)
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!"
Too Bad (Score:2, Insightful)
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.
Re:Pre-processor better?? (Score:3, Insightful)
Vision of the future (Score:4, Funny)
Am I the only one to whom this sounds like potentially a really bad idea? I mean, think about it, coding along one day:
#include
int main() {
printf("He
At this point, small, cute cartoon versions of Kernighan and Ritchie pop onto the screen and say "It looks like you're writing a Hello World program! Click here to check this program for bugs automatically..."
I'm just shuddering at the thought...
Re:Vision of the future (Score:2)
Run-time checking is slow (Score:2)
if (!infile) { perror("input file"); exit(1); }
The advantage of C is that you are allowed to not use it, if you think it's not recommended in that case.
Re:Run-time checking is slow (Score:2)
if(!shape->put())
though i know of people who bitch about things like (in perl)
if(!$x=)
{
Just one thing to say (Score:2)
I'm sorry, Dave, I can't compile that.
I know it's cliche, but really, do we expect it to be as smart as another competent programmer reviewing code?
Re:Just one thing to say (Score:2)
Sure.
Lots of us have been programming in statically-typed, safe languages for a long time. We do it not because we're poor, weak-minded programmers but because we don't have time to spend tracking down aliasing bugs and memory leaks. Though the compilers are not as "smart" (in a very strong sense) as people, they are much much more patient, and are actually very good at finding or preventing exactly these kinds of boring bugs.
Most of these languages are very abstract. (ie, SML). Cyclone is actually a project to bring some of these ideals to the systems world, where concern over data layout and memory usage are more pronounced. They've added a few useful features to C, too (polymorphism! datatypes! pattern matching!)... so I think this is a good thing, even for hardcore C cowboys.
Re:Just one thing to say (Score:2)
then we found code which had been reviewed by many different eyes without seeing these mistakes. We're just not good at doing repetative tasks, especially if we think we know what should be there. It's the the same reason we run a spell checker to check for the same word in a row, we're just not good at looking for that sort of mistake.
Why.... (Score:2)
Other than "new" and "improved" sell products better than "useful".
Re:Why.... (Score:2)
New language? (Score:5, Interesting)
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.
Re:New language? (Score:2)
There is a ring in the Inferno dedicated to people like you.
It's nothing more than built-in PC-LINT! (Score:2, Informative)
Safety in C and C++ (Score:4, Insightful)
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++ [animats.com], 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:Safety in C and C++ (Score:2)
Moon patiently told the student the following story:
"One day a student came to Moon and said: `I understand how to make a better garbage collector...
-- Jargon File
Re:Safety in C and C++ (Score:2)
A better way is to do reference tracing, where you trace all the objects which are currently in scope, and follow all their references. Anything which is not followed, is obviously collectable.
Re:Safety in C and C++ (Score:3, Interesting)
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.
Whoa, call the fact police! (Score:2)
C++ provides plenty of support for resource managements issues. The standard library includes vector, string, auto_ptr and many other related tools, all of which assist with guaranteeing memory is released properly. The fact that ill-trained C++ programmers continue to use raw arrays and pointers, when they should almost never be used beyond low-level code, is not C++'s fault.
Error 0 (Score:2, Funny)
test.c
C:\stuff\test.c(3) : 'int main(void) {' : Error 0. Program is in C. This section of code could cause problems.
Legacy Savior? A culture fix would be better... (Score:5, Insightful)
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 [cornell.edu]. 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.
there has been tool similar in purpose (Score:2, Informative)
p.
anal compilers (Score:2)
What about PC-Lint? (Score:2)
I generally don't like internal type-checking within a language, because it results in slowness, and some los of power. (Sometimes there are times you want to do things that you normally shouldn't be doing, in order to speed up routines.) A language which prevents "bad programming practice" ends up screwing itself over. However, having an external source-code checking utility that tests for bad programming, while still allowing complete power would be much more useful, to me, at least....
In defense of type systems (Score:3, Insightful)
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.
Cannot cast? (Score:2)
Probably about as effective as Grammar Check (Score:2)
Microsoft Word's grammar check has suggested to me in the past that "do it for the greater good" should probably be "do it for the greater well ".
It's sometimes helpful in helping my catch my grammar mistakes. But more often than not, it's a PITA, and the act of wading through its incorrect suggestions is more work than I think it's worth. And that's when it's SO easy to figure out if the suggestion is right or wrong...the sentence is on the screen, standing alone, and I can instantly decide if it's right or not.
Now, imagine wading through a bunch of suggestions and warnings on your code. Imagine having to figure out the context for the flagged code segnments, and having to review the code and all code which references it to see if it's correct or not.
Sure, if you've got free time or resources to throw at it, using computer heuristics to attempt to help out humans is nice. But you have to realize that at this stage in the game, it often takes a lot of work to vet those results in order to glean any gain.
Re:Probably about as effective as Grammar Check (Score:2)
Of course, there is a huge difference between a language that can be described by mathematical logic (well, almost :-), ie. Cyclone, which is supposedly designed for intent checking, and natural language, which isn't even consistent, much less mathematically consistent and describable. The restricted domain and expression structure of Cyclone may enable it to do a much better job than any rules based, context ignoring, english grammar checker ever could.
bad idea (Score:2)
i'd say more but i cut my right hand today and typing sucks.
Didn't Bill Joy announce C+++=-- in the 80's? (Score:2)
a) Computers would increase in speed, to the tune of 2^(year-1984) MIPS. [That would put us at 131,072 MIPS today, and 262,144 MIPS in a few months.]
b) He predicted the rise of a safe system programming language he called C+++=-- (pronounced "see plus plus, plus equals, minus minus), which is a safe subset of a C++ superset.
Java hadn't been invented yet, but Gosling (who was busy inventing NeWS at the time) wrote Oak aka Java several years later, and it fit the description to a tee, but just had a different name or two.
[I'll never forgive Bill Joy for writing VI and CSH. Ewwww icky yucko!]
-Don
Static verification vs. type-safe languages (Score:5, Interesting)
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:Static verification vs. type-safe languages (Score:2)
Which is impossible in Ada - wrap around semantics only happen if you specifically ask for them. The actual bug, as I've heard it told, was that the code wigged out when the physical environment became impossible for the Ariane 4 (since the code was written and designed soley for the Ariane 4.) Nothing could have found this bug without taking into consideration the differing enviroments of the Ariane 4 and 5, and that alone would have prevented the bug.
Re:Static verification vs. type-safe languages (Score:2)
> The actual bug, as I've heard it told, was that the code wigged out when the physical environment became impossible for the Ariane 4
That's correct. Something like this happened:
A: Let's build a new rocket!
B: Okay!
A: Let's reuse this "smart part" from the old one!
B: Okay!
A: Let's don't review the smart part's code, or even test it on a simulator, since it worked flawlessly on the Ariane IV!
B: Okay!
AV: Crash!
A&B: Ooops!
Hopefully everyone can spot where the plan went awry.
Here's a short from-memory explanation of what happened; you can find the official report on the Web pretty easily with a search engine:
The part in question looked at acceleration/velocity/displacement (I forget which), made some decisions about them, and put some appropriate commands on the control bus. Alas, the Ariane V was so much powerful than the IV that the acceleration/velocity/displacement soon ran up to a number that was physically impossible for the Ariane IV, so the module concluded (correctly, according to its original design) that it was getting garbage in, so it started dumping debug info on the control bus. The engines tried to interpret the debug info as control commands, with predictable results.
In lots of programs you could branch to some failsafe mode rather than dumping debug info on the bus, though it's not clear what the "failsafe mode" is for a rocket during launch. (If there were such a mode, you would just use that for your control logic to begin with!)
There's not a language, compiler, static analyzer, or theorem prover on the planet that can catch this kind of problem, though the engineers should have "caught it" during the earliest phases of the design by specifying appropriate reviews/tests for the software and software specs on the reused part.
Function pointers (Score:2)
Lacks one thing (Score:2)
"You appear to be coding with Visual Studio. Please stop!"
30 years of innovation have passed us by (Score:2)
We need to apply some of the innovations that have been built for everyone else, such as text with attributes, letting the compiler keep track of certain details, etc. Why do I have to track down every instance of a variable if I decide to change it's name? Why can't I simply change the value in the symbol table, and have the compiler spit it out with that new name when it saves it?
Why not integrate the compiler, editor, runtime, all into an effecient kernel of an environment, similar to FORTH, but with the added benefits of type checking?
It's been a long time, yet nothing has changed... what a waste.
--Mike--
Re:30 years of innovation have passed us by (Score:2)
English safety. (Score:2, Funny)
Clearly what's needed is a new version of English that doesn't permit grammatical errors.
C with safety. reminds me of a story... (Score:3, Funny)
One day, a city slicker with a spotless seersucker suit and a perfectly pointy moustache was reported travelling from station to station, selling his new technology suite. It included remote manipulators for making repairs from a higher level, without having to go under the trains. It also came equipped with "parking brakes" for trains, to prevent them accidentally moving while they were under repair.
This new "high level" technology was a hit in many towns, where the young repair technicians were unenthusiastic about life with missing limbs. In addition, the new technology came with many interlocking "safeguard" mechanisms to make sure that no fittings were left unsecured when the repair was completed. This saved many a "crash".
But there remained many towns with older engineers, who had grown up doing things the "fast" way, repairing the trains on the fly (because things went faster that way!), and of course having the scars and stumps to show for it. They were also unenthusiastic about the "safeguards", declaring that they were "smarter than any newfangled machine", and could remember to close the latches and fittings themselves.
In one of these Ancient Telegraph Towns, one of the older engineers, Cyclone Bob, came up with his answer to the newfangled "high-level machines" -- special steel braces to wear over arms and legs while repairing the moving trains. "In most every case, these braces will protect your precious limbs from the hazards of moving wheels!", enthused Cyclone Bob.
The older engineers, who, when all was said and done, actually enjoyed mucking about under trains, and who had already paid their dues in missing limbs, were rather proud of the new braces, and wore them proudly. "My trains hardly ever crash now", they would say, "and now I don't always have to lose a leg to prove it!".
The younger, smarter engineers continued using their "high-level" machines, and were happy that they still had arms so they could snigger up their sleeves.
Cyclone is good, but check out SPARK... (Score:2, Informative)
started with C...
MISRA-C is also a good effort, although somewhat
built on sand.
The safety-critical community over here in Europe,
and also a few projects in the USA use SPARK
though, which is a high-integrity, annotated
subset of Ada. It's static analysis tool
is really remarkable - anyone for static proof
of exception freedom? (e.g. static proof of
no buffer overflow for all input data)
Eiffel is also very good from a high-integrity
point of view, and well worth a look. It amazes
me how much effort goes into researching static
analysis of langauges that are simple not designed
for that purpose at all...ah well...
- Rod Chapman
Why? (Score:2)
First off, good programming practices will resolve 99% of these problems. They aren't unavoidable, they're just the result of being careless. Of the few that any good programmer will let slip through once in a while, most could probably caught with an advanced lint-like tool that checks for things in the source code, or for that matter just a little bit of peer code review. I can't see much in the way of difficult-to-avoid problems that require runtime support to adequately detect in plain old C.
In any case, a programmer's failure to be able to adequately program in C is no excuse for moving to a whole new language, compilers, runtime, libraries, standards, etc. The cost associated with migrating to the new language is excessive. It's like buying $10,000 gold-plated titanium training wheels for your sportsbike to solve your initial problem of being unable to ride the thing without falling over.
Got lint? (Score:2)
I wonder if this Cyclone makes programming "safer" by making it more difficult. What I mean by this is that some languages out there don't let you use pointers at all, or perform all sorts of checks on array bounds before each access. I like to call this "broken programming" simply because it isn't right in my opinion.
A programmer should have all tools available to him, and should choose the best tool for the job when solving any given problem. Taking away tools doesn't make programming safer--it makes programming messier.
I didn't read the article or the language description or anything, so I don't know if this is the case with Cyclone. But it certainly is with many languages. I thought this is what Lint is for. Lint is a program which performs source-level sanity checks on your code. You write your program in C and/or C++, and whenever you compile, you first run Lint to make sure everything's ok. Sure, it's not perfect, and probably won't find all problems, but it will find quite a few things wrong that you didn't even know about. (There are free and commercial implementations of various source-level things like this.)
I think that careful programming and use of a tool like Lint can make a better improvement than taking away some of the most powerful tools in programming just because some people don't know how to use them. Oh well.
disappointing speed, too complex (Score:3, Insightful)
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 [ocaml.org] or MLton [clairv.com]. 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).
Smarter than the compiler? (Score:2, Insightful)
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:But, I like being unsafe! (Score:2)
There are also some nice tricks you can sometimes play with integer-based data by casting them into integers, and doing something with them. "Going through channels" can take too much time, if you know what you're doing.
Almost everything comes down to a C or C++ base, which takes care of the dirty bits. Somebody needs to take care of the dirty bits.
That said, some people underestimate the value of staying in the channels. Whether or not the person you replied to is one of them is not something we could determine without knowing what kind of programs he writes.
Re:But, I like being unsafe! (Score:2)
No no no no no!!!!!!! Do you know how many archivers I've had to rewrite because they just cast a struct over the top of a data stream?
The only fixed size in C is the BYTE (unsigned char). Everything else will change. Never use direct memory dumps of structs for on-disk or over-net structures! When reading a data stream, read _bytes_ and convert them at runtime to the structures you desire. Now your code is not only portable across platforms, but portable across compilers, too.
Re:But, I like being unsafe! (Score:2)
Re:But, I like being unsafe! (Score:2)
Re:unix only (Score:2)
I think your second paragraph is totally bullshit. If it's not hard, why do some of the most well known linux network daemons have multiple remote buffer overflows in them? Do the people who wrote BIND, wu_ftpd, xinetd, apache, telnetd, Quake 3, Half-Life, etc. not know what they're doing? No, they know what they're doing, it's just very hard to manually secure large C programs.
The simple fact is that C encourages a style of programming that leads to these kinds of bugs. This has been a solved problem in many other languages for dozens of years now. Using a safe language, for instance, makes you totally immune to buffer overflows and format string attacks, the two most common sources of security holes in unix.
Re:How linux is an inferior desktop OS (Score:2)
experienced MCSE
See: oxymoron [m-w.com]
Remove the bloat. Most linux distro's ship with way to many useless programs. These "useless" programs must be useful to someone. Maybe not everyone, but certainly someone. If you don't want to use them, don't install them. The option is a checkbox away in most distro installs.
Dump the command line.
Granted, most users don't give a shit about the command line, or even know such a thing exists for that matter. Most of linux's power comes from the shell, though. Once you get used to it, you start to feel kind of God like.
And if you're admining a system, I'll take a shell any day over some Windows manager snap-ins or whatever the hell they're called. I don't want to be restricted to what some UI designer's whimsey.
Dump open-source.
Once the source is out there it can really be taken back, so dumping OSS is kind of impossible. Even if, for whatever imaginary reason, the Linux kernel suddenly became closed-source, all of the previous versions would still be OSS, and development would just continue along another fork.
[Desktop users] do not want to compile anything.
If a setup process involved compiling but the user couldn't see it, would that make it better? What would be the difference? In Windows, a setup.exe file unpacks some stuff, moves it around, writes some registry settings. What if some executable in linux unpacked some source code, compiled it and put it where it should go? Would that make things better for you, MCSE?
A universal gui system. Linux needs ONE gui.
First of all, choice is a good thing. Unlike Microsoft, where you're stuck with the GUI they give you, at least with UNIX-like systems you're free to choose from any number of GUIs, then proceed to configure them exactly how you want them. Right now I'm using KDE with Mosfet's Liquid engine, some NeXT-ish stuff and a bit of quartz thrown in. I like it. Other people might not, but they can roll their own. Choice.
Now, about having ONE GUI -- you mean like Windows 2000 and XP? (Okay, so can modify XP to look like 2000, but I doubt most users even know that option exists.)
Make upgrading the software easier. Desktop users need an easy way to upgrade the kernel.
This depends on the distro you're using (or if you've rolled your own), but it really isn't that hard. Here's what I do (yes, I do run Red Hat, 'cause I'm kind of attached to it. Bite me.):
1. Download a new kernel.
2. # rpm -ivh kernel*.rpm
3. Reboot.
If you're still clammoring for a GUI to do that for you, KDE and Gnome have nice package managers that will let you click your way through it. If you're using Grub, you don't even really have to do any config editing, especially with RH 7.2's kernel upgrades...
Get a good web browser.
What's wrong with Konqueror? (I don't use Gnome, so I don't know how it's browser is.) Back in the day, we used lynx and we liked it.
And that Mozilla version number stab is utter bull shit. Version numbers are arbitrary. If MSFT released their next version of IE as IE 2002, would that suddenly mean it was 2002 times better than IE 1.0? Would you compare SuSE 7.3 to RH 7.2 based on version numbers?
Proper office programs
Indeed. They're getting there. KOffice isn't terrible, and OpenOffice is okay.
These programs should be able to import all MS formats
Oh, right, you mean those MS formats that Microsoft doesn't provide specs for? Reverse engineering those things doesn't happen overnight. And I can't see MSFT suddenly opening that sort of thing up. (I can, however, see MSFT making arbitrary changes to the formats whenever reverse engineers get close...)
Backward compatibility
Not all Win16, DOS and even Win32 apps run on WinNT, 2000 and XP.
And Linux is backwardly compatible. Stuff that worked on kernel 2.2 and older work fine on 2.4. Just get the source and re-compile it. Oh, wait, source code is useless, I forgot.
J