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.""
AT&T has solved the traveling salesman problem by translating it into an input their program understands...
wasn't this supposed to be an NP-Complete problem?
I read the internet for the articles.
Not a flame, but more "modern" languages such as Java and C# have constructs explicitly built to avoid the buffer overflow/pointer gone insane problems.
For the rest of the world, secure C programing is far from a secret.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
buggy code to tell me when my code is buggy.
She sat at the window watching the evening invade the avenue.
C is *supposed* to be dangerous, damnit.
It seems to me that much of what this does could be easily implemented in a C library directly or with #define'd replacements of the C library functions in question. The type issues seem to be all that is unique here.
- Michael T. Babcock (Yes, I blog)
We had C, then C++, then C#. So shouldn't the next logical step be C followed by three vertical lines and three horizontal lines (that'd be C-tic-tac-toe)?
And isn't a cyclone an infinite loop? You have to like a scientist who uses the word humongous.
Someone created a language the enforces types and does bounds checking! It's news!
(right on the web page detailing the language)
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".
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I have been beta testing the cyclone development environment for some time now. For mature cyclone development, the amount of code output generated is equal to that being dissipated due to bug tracking. The dissipation rate per unit area is code density times the lag coefficient times the CPU speed cubed (See Emanuel 1999 for details). One could either integrate a typical code profile over a range of radii from the projects center to the outer radius encompassing the core, or assume an average CPU speed for the inner core of the system. Doing the latter and using 40 m/s (90 mph) coding on a scale of radius 60 km (40 n.mi.), one gets a code dissipation rate (bug generation rate) of 1.5 x 1012 Watts. This is equivalent to about half the world-wide script generating capacity - also an amazing amount of bugs being produced!
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.
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?
A lot of communication-based programming can involve taking a stream from some device, like a network, and simply saying casting that data into some struct, so C can access the chunks.
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.
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...
It can be done in C, if necessary:
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.
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?
A lot of the static checking made possible by Cyclone can be done for ordinary C with lclint, 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++.
-- Ed Avis ed@membled.com
Other than "new" and "improved" sell products better than "useful".
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
Seems to me PC-LINT gives you the same contextual checking... but I could be mistaken.
you're not up-to-date on some bullets
the 1.4 jdk (currently in beta) has pattern matching
parametric polymorphism (iow - templates) are in development and being called generics
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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%.
Compiling...
test.c
C:\stuff\test.c(3) : 'int main(void) {' : Error 0. Program is in C. This section of code could cause problems.
---
http://slashdot.org/moderation.shtml
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.
"Prepare for the worst - hope for the best."
lint - is name of it. And it was made 20 years ago.
p.
This sounds even more annoying than lint. :-)
(I'm not associated with this at all, but I read about it in Game Developer once, and it's really interesting.) @ Gimpel software.
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....
I heard those groans of disgust!
:-)
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.
My journal has hot
Cannot cast what I want? Oh, I feel cast-rated!!
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?
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.
get safety from the vm like java does. that way you don't have to re-write all your code. even java still has null pointer exceptions at runtime and it is regarded as very safe.
i'd say more but i cut my right hand today and typing sucks.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
A lot of communication-based programming can involve taking a stream from some device, like a network, and simply saying casting that data into some struct, so C can access the chunks.
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.
Does my bum look big in this?
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
Take a look and feel free: http://www.PieMenu.com
Java is great for applications, but you'd never want to start writing device drivers or a virtual memory system in Java. For that you need c, which is basically just a step up from assembly language. Still, people make mistakes, and this will help them.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
Bzzzt, but that's wrong too. Hint: #include <stdlib.h>, then take a look at CHAR_BIT. The number of bits per char (and "char" equals "byte" in C terminology; it's the smallest addressable piece of memory) is not specified in the language. CHAR_BIT is typically eight, but that's not certain. In practice, you can come a long way by assuming CHAR_BIT to be eight, but it's not generically true, which is why I feel the need to object a bit.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
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.
What about function pointers? What "region" do they live in? Say I create a struct with a bunch of function pointers (dur, to emulate OO), and the struct goes out of scope, what about the functions? I guess my question is, are all functions in global scope?
It's 10 PM. Do you know if you're un-American?
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.
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.
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.
You'll forgive me if I didn't write a tome on the subject :-) There's a trillion other dangers too, but somebody, at some point, when reading from the disk, has to do this, and it's probably C/C++.
Microsoft is working on a programming language called Vault that is very similar. They'll probably be using it in a future operating system to ensure that key parts of the OS, as well as first and third party drivers, behave well. If they do this, I sure hope that linux jumps on some automated technology too, because then I think they will have quite a leg up on us as far as security and stability go.
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.
A mascot. It needs a little animated tornado, maybe named Cyclonius, to pop up and interact with the user.
"You appear to be coding with Visual Studio. Please stop!"
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
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--
Clearly what's needed is a new version of English that doesn't permit grammatical errors.
http://java.sun.com/j2se/1.4/docs/api/java/util/re gex/package-summary.html
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
REGULAR EXPRESSIONS ARE NOT PATTERN MATCHING (in this context)
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.
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.
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.
Trolling, but I'll bite...
experienced MCSE
See: oxymoron
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
Cyclone is a remarkable achievement, given they
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
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.
11*43+456^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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
I've been using ada at a job for 6 months now. It is a "safe" language.
..Y is an it between -360 and 360.
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.
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.
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.
But on modern architectures, many of these design decisions are not that sensible anymore. For example, pointer arithmetic is more of a burden to modern optimizers. Languages that don't have pointer arithmetic but use array notation instead usually do as well as C in terms of performance, and often better. Similarly, the many unsafe operations in C, like "*(double *)&x" are better expressed using something that is syntactically distinguishable from a safe operation, say, "unsafe_get_bits(x,double)"; doing so involves no loss of functionality.
But language success involves a lot of psychology. Java is much more like Lisp than like C++, yet people think of it differently because of its syntax. And if it takes Cyclone to get C programmers to program in what amounts to Modula-3, so be it--the world will be better off for it.
But just because Ada is like that doesn't mean every safe systems programming language has to be like that. Modula-3 is a whole lot nicer than Ada. Sather is a whole lot nicer than Ada. And there are other examples of safe systems programming languages.
I think Cyclone has a good chance to deliver safer systems programming to C programmers in a package that they find palatable.
Seriously, I hope they'll start packaging Cyclone for Debian as well. That's a good way to get more exposure for it.
Your assertion that this is for "lazy" programmers recognizes that avoiding or fixing pointer bugs takes time and effort. Programmers spend a certain number of hours per day programming. They can spend those hours avoiding or fixing pointer bugs, or they can spend those hours improving the UI, fixing other bugs, or creating entirely new applications. I find the latter much more useful than the former.
The whole purpose of computers is to automate repetitive operations, and ensuring pointer safety seems like a very repetitive operation to me, and one that everybody makes mistakes on.
C is a fundamentally unsafe language.
.. it'll be a bit more work, of course, but blaming the C language for the incompetency of some of the people that use it seems a tad unfair. It doesn't take a whole lot of effort to innoculate C code from the type of buffer overrun attacks and memory errors that have been seen in the past. Unfortunately, a lot of people learned this lesson about 10 years too late.
..
Nonsense. It's more appropriate to say "there's a lot of poorly-written C code that is fundamentally unsafe." It's true that C has some lower-level capabilities that can potentially be used in an unsafe manner. That doesn't mean that they have to be used in an unsafe manner. A well-written C program can be just as "safe" as its Ada counterpart in terms of array bounds checking and exception handling and things of that nature
Furthermore, a flawed and insecure algorithm is going to be flawed and insecure regardless of what language is used to implement it. A "safe" language like Ada might prevent you from trashing the stack and/or writing to arbitrary regions of memory, but it's not going to prevent you from implementing a mathematically weak encryption scheme, and it won't warn you if a programmer forgets to take out a debugging back door before a piece of code is released to production. You can write poor code in any language. You can write great code in any language.
Application code, and certainly high-level code where security is essential, just aren't C's strong suits.
And yet C works well enough to implement what is perhaps the world's most secure operating system (OpenBSD.) I'm not sure what you mean by "application code" (that's an awfully wide brush you're using there.) If I wanted to write, for example, a GUI application for Unix with database access, I'd most likely use C++ and Qt. However, this choice would be based on the fact that it's a lot less work to use C++ and Qt than it would be to use something like C and GTK+. Security and safety have nothing to do with it.
I can't see how even the geniuses we're talking about can start from such a broken language
C is not a broken language. A lot of code written in C is broken. When you make this distinction, you are on the road to understanding why this bias against C is completely unjustified.
We're going down, in a spiral to the ground
Crap... I guess I'd better start writing programs, then, because I can't tell if they are going to end or not! :>
:)
Point well taken, but you can still have alot more safety in conventional languages without encountering the Halting problem. I foresee languages in the future being linked to automatic theorem provers, and even having humans assist in doing the tricky bits of the proofs.
Really, doing a formal proof of your program is the ultimate CYA.
So lottery systems tend to have redundant communications links, Tandem Non-Stop hosts, and lots of error and sanity checking. In the Mexico City earthquake, the lottery system stayed up, using its own backup radio links.
This doesn't kill the systems vendors. GTech, which runs many state lottery systems, reports that they pay out about 0.3% of revenue in penalties. Of course, they spend more than that avoiding trouble. And it works.
There are lots of cool things you just can't do easily with flat text, like tagging sections of code, perhaps to facilitate aspect oriented programming. You could show all related code in one text face, color, or whatever.
The overhead doesn't have to be great, it doesn't even have to imply a GUI, you could do it under MS-DOS (or use CURSES in GNU/Linux systems).
--Mike--
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).
I was kidding. The point was that we do the same things we've always done, except we use nifty new stuff to do it.
A deep unwavering belief is a sure sign you're missing something...
And the basic procedural programming mechanisms they use, right down to the almost identical grammar for structured programming constructs and right up to their use of exceptions to transfer control up to higher level code.
And large parts of their OO system, including the way they model with classes, objects, members, access modifiers and inheritance.
And even, if the near future unfolds as expected, such support as they have for generic types.
In other words, the underlying underlying models for each of these languages are pretty similar. There are some truly significant differences: the garbage collected memory management in Java and C#, the use of templates in C++, the use of multiple inheritance in C++ vs. interfaces elsewhere, and the standard libraries. But even these still fit into similar basic programming frameworks.
Of course, Java and C# are each used differently, idiomatically, from C++, and this is where most of the differences lie. But, when compared to the field of programming languages as a whole, they are small differences. Java and ML have big differences. C++ and Visual Basic have big differences. Java, C# and C++ are a family.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.