Whether you like them or not, exceptions greatly simplify application logic. You no longer have to consistantly check every single return value
No, they don't simplify anything and yes, you DO have to check all the return values. You just do it implicitly, and it's much harder to match up the error checks with the error generators.
Exceptions are used very rarely in C++. They do it right - they are thrown when the state of the object is destroyed by some circumstance, or some other catastrophic failure such as the new operator failing. And it is really freakin hard to make C++ throw an exception from the standard library.
So you agree with me then, exceptions are bad and shouldn't be used? The problem is that a lot of people working outside of std C++ tend to use exceptions for bits of the design they didn't bother about at the start, which turns into the crapola you have with Java where file not found is an exception. Also almost noone used the "throw ()" declaration in C++, even if they always use explicit declaration in the functions they do throw from.
Exceptions in java are not "invisible" In fact, you have to check for declared thrown exceptions (but not 'runtime' exceptions). In the API declared thrown exceptions are caused by external problems (like a missing file, closed socket, etc) while Runtime exceptions are usually caused by programmer error (like null pointers), and can be avoided by poor programming.
Ok, first of all a "file not being found" is not an exceptional condition. Secondly, yes java is required to tell you about exceptions you need to deal with (and this is a big gain over python/C++ that don't), however that doesn't solve the problem. Consider the Unix code...
#define WRSTR(fd, x) write(fd, X, strlen(X))
const char *filename = "abcd";
int out = open(filename, O_WRONLY);
if (out == -1) err(EXIT_FAILURE, "open(%s)", filename);
if (WRSTR(fd, "foo") == -1) warn("write(%s)", filename);
if (close(fd) == -1) warn("close(%s)", filename);
Now, sure that's about as bad as it gets in C... and normally you'd group a lot more data and do a single write operation. But anyway now compare that with the "wonderful Java exception code" taken from Sun's site on how to use exceptions...
PrintWriter out = null;
String filename = "abcd";
try {
out = new PrintWriter(new FileWriter(filename));
out.println("foo");
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
} finally {
if (out != null) {
out.close();
}
}
Now pretty much the first thing you see when comparing it to the C version is that an error from println is only checked once, when it's actually used twice. And close isn't checked at all. This "compiles" and seems to work fine... and as I said, this is directly from Sun's own documentation on how to use exceptions.
And I've not even mentioned how amazingly ugly it is compared to the C version, has the error checking in a non-obvious place compared to what generates the errors, could easily let someone believe that the IOException is just for the open call and it's twice as long.
If your python app is choaking on invalid input, it's because you can't program for shit, not because exceptions suck. If it was a C app, you'd simply segfault or something equally ridiculous.
Or, more likely, the error would have been checked. I assume the people who write the python code don't deliberately not check for "errors", it's just not obvious what is going to cause an error compared to the C code... and often the error checking is so far from the code that generates the errors you can miss it anyway.
C has no formal definition for exceptions (signals can't really count)
And exceptions are good, because...? Ahh yes, it's such a joy when I run a random python app. with input it didn't expect and get a screen full of exception traceback.
No, really. If I'd said to people 10 years ago, ok so there's this great idea that everyone should use called the "invisible return value". Basically what happens is that after you write to an API I can happily add extra return values you have to handle, however they'll be no possible way for you to find out what they are from looking at the code (and with most APIs I won't even declare them, so it'll basically be impossible to find out). Even better, because everyone will do this even changing what my API calls might change what I can return, and even I won't know... hahahha.
There are ways to declare side affects of functions in C, so that you can do a group of operations and only check for it in a single place. For string APIs in C SafeStr, Vstr and glib all do this in different ways. However it is often much more readable/secure to not turn explicit return values into invisible ones (or at least to provide both, Vstr does this).
The reason is simple. While I can build a system that doesn't suffer from buffer overflows in C, the only way I can guarantee this is by looking through the code - a code audit, in security parlance.
Again, this isn't true. You don't need to audit all of the code... if all of the code uses a dynamic string API, then you only need to make sure the API can't cuase problems. And as with Java where only need to know that the overflow checks work, a good implementation will come with tests to more or less prove that this is the case.
So tell me, is there an equivalent for JUnit in C?
JUnit is just a testing framework... it's writing the tests that's the hard bit. I've found automake's "make check" more than sufficient.
Is there a package like Hibernate?
Can you save objects/data to long term storage... Err Duh! Can you automatically serialize your data, sure... but not without some extra costs.
Is there introspection and reflection and casting and interfaces?
Most of these are "free" with C, however for something more formal Glib's object model provides that... along with a serialize interface (glib isn't the only thing to do that but it is everywhere and free).
I'm not sure how you'd have memory leaks in Java, since it's a garbage collected language.
GC isn't magic... or at least no implementation I know of does full lifetime analysis of every object. They just follow the references, and if they can reach an object they assume it's still being used (even if it'd obvious to a human you'll never use it again).
This basically changes the "free" operation from an explicit "free(ptr);" to "ptr = NULL;". There are times when this helps, but there are also times when it doesn't (for instance when the memory is tied to some other resource like an open file/socket)... and ignoring that you still have to free things implicitly will produce worse results.
And that isn't even mentioning languages like perl/pythong/etc. where the GC is just reference counting... and so reference loops will cuase leaks.
Now, as far as errors go: it's true that experienced programmers (in whatever language) will make fewer mistakes than less experienced programmers. But they're still human, and even if you're Donald Knuth himself, you're still going to make mistakes. The fact is that mistakes in C are far more costly than mistakes in Java. You can have off-by-one errors in both languages. In Java, however, your program will raise an out of bounds exception and, at worst, halt. In C, such a mistake could easily lead to a buffer overflow security flaw that can be exploited for elevated privilege. The same error in C and in Java is far more costly in C than in Java.
This isn't true, you can pick any of a number of string ADTs in C that make these errors exactly the same cost as in Java... and there are probably cases where you'd pick different implementations from the above. In fact I'd argue that the mental brain fart that caused Gosling to put threads into Java as a primitive operation is a far bigger problem, and a bigger source of bugs. Good experienced C programmers use a dynamic string API designed for the job and no threads, that combination happens even less often in the Java world that the C one.
I've been programming in C for years. Pointer problems aside, the main problem I've always seen with this little language is that there is no fundamental "string" data type. C++ solves this by creating the big fat bloated "string" object class. But in my opinion, there should have always been an extremely small and efficient fundamental "string" type, as in...
What is a "string"... no really. In C++ you have std::string, std::strstream, std::streambuf and now std::stringstream... which isn't even couting calling basic_string<> to create a slightly different one or using QString from Qt. I guess it's possible if there was a simple dynamic string API in ISO C people might use it, but it's not like safe dynamic string APIs don't exist. So I wouldn't put a lot of money on people using them more than they do now.
Nope. Windows has excellent hardware support. It's easy to go to the store, buy a new card or something, and get it running in Win2k.
The poster was saying that most "gamers" want something to play games on. Something they can easily put the latest 3D graphics hardware in, or the latest usb accessory... and play games with. The fact that it runs windows is irrelevant. Of course some people do want windows to succeed, mainly for monetary reasons... but I guess some people, at least at MS, must have emotional/philosophical/political reasons.
Win2k (and even XP) are gaming friendly in terms of both hardware compatibility and stability.
Frindlier than Linux, right now, almost certainly... but it's a hell of a lot less friendly than a PS2, GameCube or even an Xbox.
It is possible to do with one thread, but if you have a UI thread and a network thread, you get everything redrawing nicely for free.
It's pretty easy to do right with one thread, it's _much harder_ to do right with more than one thread... however it is often implemented badly quicker with multiple threads (like mozilla, I'm sure it was easier to start with to multithread it... but it's now years later and the best addon is still that galeon allows you to restore you session when mozilla deadlocks or crashes).
My main gripe is people who use non-standard defines from header files, put broken assumptions into configure scripts, etc.
Do you want some cheese with that wine? autoconf scripts are there explicitly for portability, otherwise we'd just write crappy makefiles that don't run anywhere else... like most *BSD software (see openssh for the obvious example, but if I want an RPM for FreeBSD's make can I get it easily -- hell no).
This is a cultural problem, where there is a vast naivte/ignorance/arrogance among OSS programmers who think only GNU/Linux counts for anything and that people who use Solaris/BSD/whatever should go rot somewhere.
I'll buy some ignorance, sure. However here's a clue, only a very small amount of Linux developers have access to a *BSD box. So do you make it easier... no. A couple of weeks after Linux got a sendfile() syscall, FreeBSD discussed it and then introduced a version that was incompatilby different... for no good reason. TCP_CORK... introduced into Linux, happily ignored in FreeBSD (well hey they have TCP_PUSH which does almost the same thing, but is just different enough to break anything that would try and use both). getsockopt(SO_PEERCRED), introduced into Linux... getpeereid() in openbsd. And let us not forget mremap in Linux... NIH in FreeBSD land. And you really don't want to discuss the make "issues", I mean we only provided portability to all your OSes, a nicer syntax, and then a social move to automake so you could use your crappy variant with our software.
So after all this pain and suffering you make the majority of us go through, do we get any help porting to or installing *BSD... hell no, it's much more fun to heckle from the cheapseats.
In case you've forgotten, you're in the minority... we don't "owe" you anything... we aren't going to have to conform anytime soon. However the majority of us will respond to kind words and offers of help (even if it's only, I've got no time/idea but here's a login... or even just here's the error message).
More and more musicians are going to start to realize that detaching yourself from your label and going independent can get you more money on 1/10 the sales, because you get to keep it.
I've seen this said a few times now, and while it's cute I don't think it's the primary motivator. Money is nice, and while my OpenSource work helps getting that it sure as hell isn't my primary motivativation. I can only assume that musicians have a similar value system.
So instead of marketing that you'll get more money for a 1/10 of the sales instead people should be saying "You'll get 1,000 times as many listeners and more money". The day it becomes obvious that the only way to get heard by the majority of the audience is to "give away" the music for personal use is the day the RIAA dies.
Um. What would be the problem with a web based interface? Obviously you haven't seen very many web based applications.
In my experience web interfaces come in three flavours...
Simple: Think amazon order page, or eBay. These work well using just normal html but do very little. If you use them every now and again they are pretty good, if you use them a lot it can become annoying having to be so constrained.
Hack job: These try to do something slightly more advanced (which could always just be better designed to be a "simple" interface as above), often require java/javascript without good cause, break on different browsers and are often more painful to use even if you have the "right" browser. The only reason for existance is that the programer can't design good interfaces and/or like "cute" menus etc. that don't work. A good examples are buy.com when I last used it (it's possible it's improved) and most of the timecard applications (Ohh let's require java and javascript for simple a goddamn form).
Real apps: These are real applications, they require java/javscript/flash/whatever
although they almost always are only tested on win32 and would always be better off being written in some portable real language (like Java with SWT, python with wxwindows, or just VB if you only care about win32). Good examples are yahoo games and
I help write a commercial one for a living, and our web based interface is very desktop application like, and it works in both Mozilla and IE.
I can guarantee it doesn't work in my version of mozilla (java and javascript turned off for security). And the great thing about the web before stupid people decided to try and write Excel on it was that I could do the same thing with lynx, or gtkhtml, or dillo, or...
We have even have ctrl-shift multiple selections so you can open multiple records at once, or you can double click a single record in a listing to open it.
So go write in Java or python, or whatever, the people who need to use your "application" will be happier because it'll actually be an application and you will be able to drag and drop and all the other stuff to act like a real application does. And all of the people using lynx, or dillo or whatever can be happy that you've got off the web.
Dynamic strings are fine--until you run out of memory.
Whether static or dynamic, there is, eventually, a limit you'll run into, and if you don't code with that limit in mind then, eventually, you'll be screwed. In some cases, static allocation can be better because you know ahead of time what the limit is.
I'm guessing you didn't read my links, so let me spell it out...
It's none trivial to run out of memory, and even if you do it's "only" a DOS attack.
As I said before, there are a lot of mistakes that you can do using a limited string API alloc which can be much worse that a DOS atttack (buffer overflows, privilage escalation, information leakage).
You almost always need to use more memory when using a limited string API than when using a dynamic string API, as you need to allocate the maximum amount of space (see this article I wrote in comp.lang.c).
As well as more memory, you often need more CPU because you have to do more copies of the data (esp. given that more than a few dynamic string APIs let you share data between strings).
Sometimes you don't know the maximum amount needed, and so if you are using a limited string API then you'll now have to use two sets of string APIs.
Of course there's also the real life test, assuming you leave out the C library with extentions model that apache, squid, openssh, sendmail, nfs, etc. have all tried to use (and all had buffer overflows with) the only one daemon I can think of using a limited string API is samba... and supprise, supprise that's had buffer overflows too. So can you name one application that uses a limited string API and hasn't had a buffer overflow
I'm not sure that "insecure by design" is quite fair to the hard-working folks who developed this near-ubiquitous MTA.
So are you saying it is designed with security in mind?
A fairer assessment is that, when sendmail was designed, security was not as big an issue as it has become today.
So you saying (agreeing) it is designed without security in mind.
It's been years since the internet operated where everyone allowed relaying to help everyone else out. And go look at the code, they still use NIL terminated char *'s all over the place. Mostly with limited length APIs like strlcpy(), but even a few strcpy()s.
Now go look at postfix or qmail, but have fully dynamic string APIs and use them everywhere. And supprise supprise neither has had a buffer overflow.
bug 211205, which deals with this expoit, was resolved in 2h after the announcement. I had my box patched 15min after the slashdot story hit.
Yeh, just a pity about the exim exploit that took a couple of weeks for them to fix.
Re:Yet languages make a big difference
on
Secure Programming
·
· Score: 1
By over 50%, you mean, 43%? Also, this figure assumes that the string library will be used correctly, which,
Well it obviously changes with each security errata released. For instance it'll go up a little today due to the second ssh problem that could have been avoided by use of a real string library.
But yes it's was at 43%, for any half ok string library, when you looked. So possible around 50% would have been better wording. However if you classify the problems with a severity level (not finished, but something I'm going to do for that page). You see that almost all the ones that allow the attacker to control your machine go away (the other being DOS attacks, or things like the w3m XSS problem... which I could happily ignore for weeks.
Perhaps using a new API will give some security benefit if you use it correctly.
The security benifit isn't just that some attacks don't do anything, it's that other attacks (like integer overflows -- if they happen) go from overflowing the heap/stack so the attacker can control your application to being plain DOS attacks. The former is something I/everyone have to maddly rush around applying patches/work arounds for (like I'm currently madly turning ssh off on a bunch of boxes until RH release an errata), the later is something that I can wait for. Big difference.
It was a sieve of Erathostenes implementation that we did for several languages. Results are here.
Ok, so I downloaded the code from cvs (it's in the examples directory for anyone else). This doesn't look even remotely like a valid test for C vs. Dylan (hell the linked to article even has "Rigged Benchmarks" as it's title).
The first thing that's needed is a test with some function calls and passed pointers, which is more like real life... and at which point the bounds checking code will have to do less well.
Also it looks like the benchmark is blowing the cache on most CPUs.
But even with the rigged benchmark C is still 11% faster than Dylan with bounds checking (the fact that Dylan without bounds checking is still 10% slower than C doesn't mean that it costs only 1% or.4% (which is the percentage difference between the two Dylan results) for bounds checking.
The thing with new string libraries is that there's a lot of code out there that doesn't use them and which you need to use to get productive in C, and that there's not only strings, but also a lot of other kinds of arrays, vectors and buffers that need to be checked. Even if your own code is fine, a lot of third party code isn't, and will never be.
Sure even if you use a string library, the bits that aren't using a string library are still vulnerable... Duh. Although I'd argue that vectors/arrays are generally easier to deal with (often are either easily limited or use something else like a linked list instead), and "buffers" is just another name for string.
However you seem to be implying that changing the string using parts of your app. to a string library is somehow harder than re-writting your application in a completely new language. Sorry, I don't believe it.
And CPAN shows that it is entirely possible to implement a wide and useful range of libraries for a language different than C.
And significant parts of CPAN are perl interfaces to C shared libraries.
Re:We really need a different language
on
Secure Programming
·
· Score: 1
Really if it were that simple, people would have written and used SMTP/HTTP/SSH servers in python or whatever.
This I don't agree with. In fact, in a couple weekends I rewrote ftpd in SML, because I got fed up with buffer overflows in wu_ftpd. It was really easy, and the code went from something like 24,000 lines to 3,500 (including an implementation of MD5 and MD5_crypt, and some other general server stuff that I reuse in other projects). I plan to rewrite others, especially sshd which has had a number of annoying vulnerabilities recently. I don't see any reason why a team of good hackers couldn't port the basic functionality of a number of standard services in a short period, and it would certainly help users sleep more soundly at night!
Well I might still need to use apache in some places due to the mod_* usage. But I'd pretty quickly change SMTP, DNS and SSH if someone did competetive versions that used either a real string library or ML (or dylan, or whatever -- so long as it's as free as python/perl).
However note the competetive attribute, I've seen a web server that was written in 569 lines of C... and it even worked well enough that it was useful (it was _very_ easy to boot a quick version with a non-std. port to get around some DSL "security"). However it wasn't/isn't competitive, with apache. In the same vain, I'd want something at least as nice as exim/postfix for SMTP or vsftpd for FTP.
I'm not going to hold my breath, and I expect I'll get a version with a string library in C before you do one in ML... but maybe you can prove me wrong:).
Re:We really need a different language
on
Secure Programming
·
· Score: 1
Linux is over 30 million lines, and there is no fucking way that all has to be in C. It would be possible to do bounds checking and even garbage collection in most parts the kernel. (Real-time garbage collection has been done!) Using a microkernel architecture, lots and lots of code (say, the filesystem) could be written in a high-level, safe language. Doing this has various tradeoffs--speed is one that might bother the slashdot audience. Personally, I'd love to use such a system, because I care more about my computer working correctly than working fast.
And yet all of the "main" kernels are all in C or C++.
For the vast majority of computer software, especially network software where security holes are most disastrous, modern safe languages are better in almost every dimension: fewer security holes, more maintainable code, less code to verify, etc. Other than "legacy code" and "legacy programmers," it baffles me that C remains so popular.
But yet, if you want a box that has a database, web server, allows you to login (with crypto) and sends email then there are none, ZERO, nadda choices but C. Well maybe roxen web server counts, but that includes it's own interpreter... so I'd say not.
Really if it were that simple, people would have written and used SMTP/HTTP/SSH servers in python or whatever. Maybe in a few years people will really not care about performance enough for it to happen, but that's certainly not the case now.
Re:Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
I mean, yikes. Security is not the only reason to use a high-level language; ease in expressing your ideas is another. It allows you to spend time thinking about the difficult questions in security instead of repeating tedious details.
Sure, that's true. But most programs are bigger than "hello world". And as the tutorial says, the actual meat of the Vstr version (Ie. the bit you'd have to actually write most of the time) is...
Which is still longer than doing perl -e '$a = "hello" . " " . "world\n";', but the vstr code also does something very different internally which can reduce memory overhead and CPU cycles in many cases. There are also other APIs which are much closer to the implementation of perl strings. And it is also much easier to put into a C program (where you've chosen the language based on other reasons than just how to handle a string concatenation at one point).
I'm not saying that using other languages are bad, just that this mantra of saying you get buffer overflows from using strcpy() in C so everyone should use another language is misguided. It just means that everyone ignores everyone else.
Re:Interepreted languages help, but aren't a cure-
on
Secure Programming
·
· Score: 1
Buffer overflows are arguably the most common vulnerabilities that occur in the wild, which in turn indicates that most of the network services attacked are being written in C.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
This is very true, if only Universityies offered something like "CS 104 - Thinking like an adversary", which is a bit different from how programmers normally think about their code. Ahh. well, someday.
Well, according to measurements we have done, the bounds checking overhead is less than 0.1%. But in the case described by you, the compiler can do even better.
You mean on Dylan, I find that hard to believe. What kind of workload was that?
Anyway that requires rewritting your application in a language that very few people have ever written anything in. The stats I've seen for adding bounds checking into C affect the performance by about 100x (10-15%) IIRC. Hell the performance of doing stack guard/pro-police like checks were in the 1-2% region.
As for the compiler is magic nowadays, well maybe your compiler... but the ones I've used, for C, still have a long way to go just doing constant propagaion/cse/etc. to get inlining to be as good as a programer could.
In some analysis I've done on C String APIs you can get very close to "raw" C with good/secure dynamic string APIs... and even better than the obvious approach in some cases. And I think it'll be somewhat easier to get C programers to learn a C API and take a very small performance hit in some cases than it will to get them all to write everything in dylan, or Java or python, etc.
Re:Scripting languages have problems, too ...
on
Secure Programming
·
· Score: 1
Sure. And there are languages that avoid buffer overruns (and double-frees, something which C can't really protect against without doing garbage collection, and format string bugs, and integer overflows), too, and people stick with C due to lack of awareness.
Getting people to use a string library is much easier than getting the to rewrite all their code in a new language, or even create new code in a language they haven't used much before.
And to reiterate there has been a single double free security errata for Red Hat this year. There is also one free while in use security errata (but that was in a printf() function that apache has no business implementing IMO, so the fact it's broken in more than just std. conformance doesn't supprise me).
IIRC there was a single double free from last year too, in zlib, however I don't have stats for that yet.
Re:Yet languages make a big difference
on
Secure Programming
·
· Score: 1
In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD hole, etc.)
All of these errors would be impossible to make in a safe language.
Of all the Remote Security Vulnerabilities that Red Hat has released over the last year over 50% are are impossible to make with dynamic string APIsin C. The rest are almost all cross site scripting, various DOS attacks and temporary file vulnerabilities which affect python/perl/etc. programs just as much.
Really, you don't need to buy a new car because the one you have has a tape deck and not a CD p0layer. Language doesn't matter in this way.
Slashdot Mirror
No, they don't simplify anything and yes, you DO have to check all the return values. You just do it implicitly, and it's much harder to match up the error checks with the error generators.
So you agree with me then, exceptions are bad and shouldn't be used? The problem is that a lot of people working outside of std C++ tend to use exceptions for bits of the design they didn't bother about at the start, which turns into the crapola you have with Java where file not found is an exception. Also almost noone used the "throw ()" declaration in C++, even if they always use explicit declaration in the functions they do throw from.
Ok, first of all a "file not being found" is not an exceptional condition. Secondly, yes java is required to tell you about exceptions you need to deal with (and this is a big gain over python/C++ that don't), however that doesn't solve the problem. Consider the Unix code...
#define WRSTR(fd, x) write(fd, X, strlen(X)) const char *filename = "abcd"; int out = open(filename, O_WRONLY); if (out == -1) err(EXIT_FAILURE, "open(%s)", filename); if (WRSTR(fd, "foo") == -1) warn("write(%s)", filename); if (close(fd) == -1) warn("close(%s)", filename);Now, sure that's about as bad as it gets in C ... and normally you'd group a lot more data and do a single write operation. But anyway now compare that with the "wonderful Java exception code" taken from Sun's site on how to use exceptions...
PrintWriter out = null; String filename = "abcd"; try { out = new PrintWriter(new FileWriter(filename)); out.println("foo"); } catch (IOException e) { System.err.println("Caught IOException: " + e.getMessage()); } finally { if (out != null) { out.close(); } }Now pretty much the first thing you see when comparing it to the C version is that an error from println is only checked once, when it's actually used twice. And close isn't checked at all. This "compiles" and seems to work fine ... and as I said, this is directly from Sun's own documentation on how to use exceptions.
And I've not even mentioned how amazingly ugly it is compared to the C version, has the error checking in a non-obvious place compared to what generates the errors, could easily let someone believe that the IOException is just for the open call and it's twice as long.
Or, more likely, the error would have been checked. I assume the people who write the python code don't deliberately not check for "errors", it's just not obvious what is going to cause an error compared to the C code ... and often the error checking is so far from the code that generates the errors you can miss it anyway.
And exceptions are good, because...? Ahh yes, it's such a joy when I run a random python app. with input it didn't expect and get a screen full of exception traceback.
No, really. If I'd said to people 10 years ago, ok so there's this great idea that everyone should use called the "invisible return value". Basically what happens is that after you write to an API I can happily add extra return values you have to handle, however they'll be no possible way for you to find out what they are from looking at the code (and with most APIs I won't even declare them, so it'll basically be impossible to find out). Even better, because everyone will do this even changing what my API calls might change what I can return, and even I won't know ... hahahha.
There are ways to declare side affects of functions in C, so that you can do a group of operations and only check for it in a single place. For string APIs in C SafeStr, Vstr and glib all do this in different ways. However it is often much more readable/secure to not turn explicit return values into invisible ones (or at least to provide both, Vstr does this).
JUnit is just a testing framework ... it's writing the tests that's the hard bit. I've found automake's "make check" more than sufficient.
Can you save objects/data to long term storage ... Err Duh! Can you automatically serialize your data, sure ... but not without some extra costs.
Most of these are "free" with C, however for something more formal Glib's object model provides that ... along with a serialize interface (glib isn't the only thing to do that but it is everywhere and free).
GC isn't magic ... or at least no implementation I know of does full lifetime analysis of every object. They just follow the references, and if they can reach an object they assume it's still being used (even if it'd obvious to a human you'll never use it again).
This basically changes the "free" operation from an explicit "free(ptr);" to "ptr = NULL;". There are times when this helps, but there are also times when it doesn't (for instance when the memory is tied to some other resource like an open file/socket) ... and ignoring that you still have to free things implicitly will produce worse results.
And that isn't even mentioning languages like perl/pythong/etc. where the GC is just reference counting ... and so reference loops will cuase leaks.
This isn't true, you can pick any of a number of string ADTs in C that make these errors exactly the same cost as in Java ... and there are probably cases where you'd pick different implementations from the above. In fact I'd argue that the mental brain fart that caused Gosling to put threads into Java as a primitive operation is a far bigger problem, and a bigger source of bugs. Good experienced C programmers use a dynamic string API designed for the job and no threads, that combination happens even less often in the Java world that the C one.
What is a "string" ... no really. In C++ you have std::string, std::strstream, std::streambuf and now std::stringstream ... which isn't even couting calling basic_string<> to create a slightly different one or using QString from Qt. I guess it's possible if there was a simple dynamic string API in ISO C people might use it, but it's not like safe dynamic string APIs don't exist. So I wouldn't put a lot of money on people using them more than they do now.
The poster was saying that most "gamers" want something to play games on. Something they can easily put the latest 3D graphics hardware in, or the latest usb accessory ... and play games with. The fact that it runs windows is irrelevant. Of course some people do want windows to succeed, mainly for monetary reasons ... but I guess some people, at least at MS, must have emotional/philosophical/political reasons.
Frindlier than Linux, right now, almost certainly ... but it's a hell of a lot less friendly than a PS2, GameCube or even an Xbox.
It's pretty easy to do right with one thread, it's _much harder_ to do right with more than one thread ... however it is often implemented badly quicker with multiple threads (like mozilla, I'm sure it was easier to start with to multithread it ... but it's now years later and the best addon is still that galeon allows you to restore you session when mozilla deadlocks or crashes).
Do you want some cheese with that wine? autoconf scripts are there explicitly for portability, otherwise we'd just write crappy makefiles that don't run anywhere else ... like most *BSD software (see openssh for the obvious example, but if I want an RPM for FreeBSD's make can I get it easily -- hell no).
I'll buy some ignorance, sure. However here's a clue, only a very small amount of Linux developers have access to a *BSD box. So do you make it easier ... no. A couple of weeks after Linux got a sendfile() syscall, FreeBSD discussed it and then introduced a version that was incompatilby different ... for no good reason. TCP_CORK ... introduced into Linux, happily ignored in FreeBSD (well hey they have TCP_PUSH which does almost the same thing, but is just different enough to break anything that would try and use both). getsockopt(SO_PEERCRED), introduced into Linux ... getpeereid() in openbsd. And let us not forget mremap in Linux ... NIH in FreeBSD land. And you really don't want to discuss the make "issues", I mean we only provided portability to all your OSes, a nicer syntax, and then a social move to automake so you could use your crappy variant with our software.
So after all this pain and suffering you make the majority of us go through, do we get any help porting to or installing *BSD ... hell no, it's much more fun to heckle from the cheapseats.
In case you've forgotten, you're in the minority ... we don't "owe" you anything ... we aren't going to have to conform anytime soon. However the majority of us will respond to kind words and offers of help (even if it's only, I've got no time/idea but here's a login ... or even just here's the error message).
I've seen this said a few times now, and while it's cute I don't think it's the primary motivator. Money is nice, and while my OpenSource work helps getting that it sure as hell isn't my primary motivativation. I can only assume that musicians have a similar value system.
So instead of marketing that you'll get more money for a 1/10 of the sales instead people should be saying "You'll get 1,000 times as many listeners and more money". The day it becomes obvious that the only way to get heard by the majority of the audience is to "give away" the music for personal use is the day the RIAA dies.
In my experience web interfaces come in three flavours...
I can guarantee it doesn't work in my version of mozilla (java and javascript turned off for security). And the great thing about the web before stupid people decided to try and write Excel on it was that I could do the same thing with lynx, or gtkhtml, or dillo, or...
So go write in Java or python, or whatever, the people who need to use your "application" will be happier because it'll actually be an application and you will be able to drag and drop and all the other stuff to act like a real application does. And all of the people using lynx, or dillo or whatever can be happy that you've got off the web.
I'm guessing you didn't read my links, so let me spell it out...
It's none trivial to run out of memory, and even if you do it's "only" a DOS attack.
As I said before, there are a lot of mistakes that you can do using a limited string API alloc which can be much worse that a DOS atttack (buffer overflows, privilage escalation, information leakage).
You almost always need to use more memory when using a limited string API than when using a dynamic string API, as you need to allocate the maximum amount of space (see this article I wrote in comp.lang.c).
As well as more memory, you often need more CPU because you have to do more copies of the data (esp. given that more than a few dynamic string APIs let you share data between strings).
Sometimes you don't know the maximum amount needed, and so if you are using a limited string API then you'll now have to use two sets of string APIs.
Of course there's also the real life test, assuming you leave out the C library with extentions model that apache, squid, openssh, sendmail, nfs, etc. have all tried to use (and all had buffer overflows with) the only one daemon I can think of using a limited string API is samba ... and supprise, supprise that's had buffer overflows too. So can you name one application that uses a limited string API and hasn't had a buffer overflow
So are you saying it is designed with security in mind?
So you saying (agreeing) it is designed without security in mind.
It's been years since the internet operated where everyone allowed relaying to help everyone else out. And go look at the code, they still use NIL terminated char *'s all over the place. Mostly with limited length APIs like strlcpy(), but even a few strcpy()s.
Now go look at postfix or qmail, but have fully dynamic string APIs and use them everywhere. And supprise supprise neither has had a buffer overflow.
Yeh, just a pity about the exim exploit that took a couple of weeks for them to fix.
Well it obviously changes with each security errata released. For instance it'll go up a little today due to the second ssh problem that could have been avoided by use of a real string library.
But yes it's was at 43%, for any half ok string library, when you looked. So possible around 50% would have been better wording. However if you classify the problems with a severity level (not finished, but something I'm going to do for that page). You see that almost all the ones that allow the attacker to control your machine go away (the other being DOS attacks, or things like the w3m XSS problem ... which I could happily ignore for weeks.
The security benifit isn't just that some attacks don't do anything, it's that other attacks (like integer overflows -- if they happen) go from overflowing the heap/stack so the attacker can control your application to being plain DOS attacks. The former is something I/everyone have to maddly rush around applying patches/work arounds for (like I'm currently madly turning ssh off on a bunch of boxes until RH release an errata), the later is something that I can wait for. Big difference.
Ok, so I downloaded the code from cvs (it's in the examples directory for anyone else). This doesn't look even remotely like a valid test for C vs. Dylan (hell the linked to article even has "Rigged Benchmarks" as it's title).
The first thing that's needed is a test with some function calls and passed pointers, which is more like real life ... and at which point the bounds checking code will have to do less well.
Also it looks like the benchmark is blowing the cache on most CPUs.
But even with the rigged benchmark C is still 11% faster than Dylan with bounds checking (the fact that Dylan without bounds checking is still 10% slower than C doesn't mean that it costs only 1% or .4% (which is the percentage difference between the two Dylan results) for bounds checking.
Sure even if you use a string library, the bits that aren't using a string library are still vulnerable ... Duh. Although I'd argue that vectors/arrays are generally easier to deal with (often are either easily limited or use something else like a linked list instead), and "buffers" is just another name for string.
However you seem to be implying that changing the string using parts of your app. to a string library is somehow harder than re-writting your application in a completely new language. Sorry, I don't believe it.
And significant parts of CPAN are perl interfaces to C shared libraries.
Well I might still need to use apache in some places due to the mod_* usage. But I'd pretty quickly change SMTP, DNS and SSH if someone did competetive versions that used either a real string library or ML (or dylan, or whatever -- so long as it's as free as python/perl).
However note the competetive attribute, I've seen a web server that was written in 569 lines of C ... and it even worked well enough that it was useful (it was _very_ easy to boot a quick version with a non-std. port to get around some DSL "security"). However it wasn't/isn't competitive, with apache. In the same vain, I'd want something at least as nice as exim/postfix for SMTP or vsftpd for FTP.
I'm not going to hold my breath, and I expect I'll get a version with a string library in C before you do one in ML ... but maybe you can prove me wrong :).
And yet all of the "main" kernels are all in C or C++.
But yet, if you want a box that has a database, web server, allows you to login (with crypto) and sends email then there are none, ZERO, nadda choices but C. Well maybe roxen web server counts, but that includes it's own interpreter ... so I'd say not.
Really if it were that simple, people would have written and used SMTP/HTTP/SSH servers in python or whatever. Maybe in a few years people will really not care about performance enough for it to happen, but that's certainly not the case now.
Sure, that's true. But most programs are bigger than "hello world". And as the tutorial says, the actual meat of the Vstr version (Ie. the bit you'd have to actually write most of the time) is...
Which is still longer than doing perl -e '$a = "hello" . " " . "world\n";', but the vstr code also does something very different internally which can reduce memory overhead and CPU cycles in many cases. There are also other APIs which are much closer to the implementation of perl strings. And it is also much easier to put into a C program (where you've chosen the language based on other reasons than just how to handle a string concatenation at one point).
I'm not saying that using other languages are bad, just that this mantra of saying you get buffer overflows from using strcpy() in C so everyone should use another language is misguided. It just means that everyone ignores everyone else.
No, it's not arguable, here's some stats. However it doesn't require a new language to solve this problem.
This is very true, if only Universityies offered something like "CS 104 - Thinking like an adversary", which is a bit different from how programmers normally think about their code. Ahh. well, someday.
You mean on Dylan, I find that hard to believe. What kind of workload was that?
Anyway that requires rewritting your application in a language that very few people have ever written anything in. The stats I've seen for adding bounds checking into C affect the performance by about 100x (10-15%) IIRC. Hell the performance of doing stack guard/pro-police like checks were in the 1-2% region.
As for the compiler is magic nowadays, well maybe your compiler ... but the ones I've used, for C, still have a long way to go just doing constant propagaion/cse/etc. to get inlining to be as good as a programer could.
In some analysis I've done on C String APIs you can get very close to "raw" C with good/secure dynamic string APIs ... and even better than the obvious approach in some cases. And I think it'll be somewhat easier to get C programers to learn a C API and take a very small performance hit in some cases than it will to get them all to write everything in dylan, or Java or python, etc.
Getting people to use a string library is much easier than getting the to rewrite all their code in a new language, or even create new code in a language they haven't used much before.
And to reiterate there has been a single double free security errata for Red Hat this year. There is also one free while in use security errata (but that was in a printf() function that apache has no business implementing IMO, so the fact it's broken in more than just std. conformance doesn't supprise me).
IIRC there was a single double free from last year too, in zlib, however I don't have stats for that yet.
Of all the Remote Security Vulnerabilities that Red Hat has released over the last year over 50% are are impossible to make with dynamic string APIs in C. The rest are almost all cross site scripting, various DOS attacks and temporary file vulnerabilities which affect python/perl/etc. programs just as much.
Really, you don't need to buy a new car because the one you have has a tape deck and not a CD p0layer. Language doesn't matter in this way.