In the present political climate in which government powers are conferred, without a counterbalancing obligation of accountability, onto private bodies, the loss will be much greater.
Which, I think is precisely the problem. We don't get an uncensored Net, we only get to choose the censors. In the U.S., the Net isn't censored by the government simply because allowing people to visit "questionable" sites gives the government the ability to compile a list of terrorism suspects.
Really, the problem is much more insidious than that - how many people know that AOL filters their content? When it comes down to it, while we decry other countries for their draconian censorship, we ourselves have merely moved the censorship from the government (who are 'accountable' to the public at large) to American corporations (who are accountable to no one, as Enron has shown). I fear the latter more than the former, because unlike governmental oppression, corporate suppression of free speech is not covered by the constitution!
Really, the Net is no longer a geek's toy. It is now the Net of the masses, and we can expect that things will get worse. The average person has no use for Linux kernals or for distributing free software, so you can expect these to go first. Indeed, as the SCO case has shown, Corporate America can effectively outlaw the distribution of anything that infringes on their income model by doing little more than filing a lawsuit.
Yeah, it's changing. The Internet is only as free as its users, and slaves are signing up in droves.
After that, maybe we can look into programming languages that actually have a string type, and don't tend to make every bug exploitable by default.
Yeah, whatever. Why not teach people to write correct code instead. And BTW, what happens when your String class runs out of memory? (Yes, I've seen code which reads an entire file into a String....) So I guess it's better to segfault than risk buffer overrun?
After programming in C++ for a number of years, I've stopped using the string types, and actually gone back to using regular C-style strings. Here's why:
The String types dynamically allocate memory. Hence, an operation such as this:
string1 = string2 + string3;
can fail. This doesn't leave you with any options; either you wrap every string assignment in try/catch blocks, or you just hope it works. Compare this with the following in C:
The above code can't possibly fail. There's no need for try/catch, or needless error checking - the destination array will always be large enough.
With the datasets I've been using, I quite frequently run out of memory. Since a string allocates memory on the fly, any memory allocation failure will happen in the middle of the algorithm, rather than before it - at which point recovery is pretty much impossible. By using safeguards such as the above and allocating memory before I begin processing, I can alert the user to a memory allocation problem before the processing has begun. Thus, my users can be relatively certain that a long operation really will succeed, rather than running out of memory at the last minute.
malloc has some notable bugs in it - it often hangs when allocating numerous small chunks of memory; when it does, no amount of exception handling will bring control back to your program. Because of this, it's actually better to allocate a large chunk of memory at the outset and parcel it out as the program needs it, rather than running the risk of hanging the machine with a large number of calls to malloc.
When it comes down to it, every computer has limited memory. The difference between those programs written using a C++ String and a C-style string is that a program written uses c-style strings does not allow the programmer to forget that memory is limited. A C++ programmer, OTOH, will write as if there's no limit to memory, and hopes that someone won't process a particularly large file, or his program will crash. Unlike the C++ programmer, the C programmer must choose an algorithm that can work within a given space requirement, and hence, the size of the data processed becomes irrelevant - it simply takes more time, rather than segfaulting, or worse, hanging the machine.
I could go on about how my university taught students to allocate memory but not to free it, but I'll spare you. I think the real problem is that the illusion of infinite memory is just that - an illusion. While the String types have some nice features, everything done with a String type can be done with C-style strings, and if it can't, it's usually trivial to implement. With C-style strings, I can formally prove the correctness of an algorithm, but not with the String types, simply because their behavior is not well defined for cases in which memory allocation fails. Even if these string types had a standard behavior, you're still left with an algorithm that becomes useless when memory allocation fails.
And do you know for certain that the String type isn't immune to buffer overflow? If your program crashed because of excess input, would it escape back to a root-level shell? When it comes down to it, security requires more thought than just using some nifty-yet-formally-incomplete classes.
Slashdot Mirror
Which, I think is precisely the problem. We don't get an uncensored Net, we only get to choose the censors. In the U.S., the Net isn't censored by the government simply because allowing people to visit "questionable" sites gives the government the ability to compile a list of terrorism suspects.
Really, the problem is much more insidious than that - how many people know that AOL filters their content? When it comes down to it, while we decry other countries for their draconian censorship, we ourselves have merely moved the censorship from the government (who are 'accountable' to the public at large) to American corporations (who are accountable to no one, as Enron has shown). I fear the latter more than the former, because unlike governmental oppression, corporate suppression of free speech is not covered by the constitution!
Really, the Net is no longer a geek's toy. It is now the Net of the masses, and we can expect that things will get worse. The average person has no use for Linux kernals or for distributing free software, so you can expect these to go first. Indeed, as the SCO case has shown, Corporate America can effectively outlaw the distribution of anything that infringes on their income model by doing little more than filing a lawsuit.
Yeah, it's changing. The Internet is only as free as its users, and slaves are signing up in droves.
Yeah, whatever. Why not teach people to write correct code instead. And BTW, what happens when your String class runs out of memory? (Yes, I've seen code which reads an entire file into a String....) So I guess it's better to segfault than risk buffer overrun?
After programming in C++ for a number of years, I've stopped using the string types, and actually gone back to using regular C-style strings. Here's why:
-
The String types dynamically allocate memory. Hence, an operation such as this:
-
With the datasets I've been using, I quite frequently run out of memory. Since a string allocates memory on the fly, any memory allocation failure will happen in the middle of the algorithm, rather than before it - at which point recovery is pretty much impossible. By using safeguards such as the above and allocating memory before I begin processing, I can alert the user to a memory allocation problem before the processing has begun. Thus, my users can be relatively certain that a long operation really will succeed, rather than running out of memory at the last minute.
-
malloc has some notable bugs in it - it often hangs when allocating numerous small chunks of memory; when it does, no amount of exception handling will bring control back to your program. Because of this, it's actually better to allocate a large chunk of memory at the outset and parcel it out as the program needs it, rather than running the risk of hanging the machine with a large number of calls to malloc.
When it comes down to it, every computer has limited memory. The difference between those programs written using a C++ String and a C-style string is that a program written uses c-style strings does not allow the programmer to forget that memory is limited. A C++ programmer, OTOH, will write as if there's no limit to memory, and hopes that someone won't process a particularly large file, or his program will crash. Unlike the C++ programmer, the C programmer must choose an algorithm that can work within a given space requirement, and hence, the size of the data processed becomes irrelevant - it simply takes more time, rather than segfaulting, or worse, hanging the machine.string1 = string2 + string3;
can fail. This doesn't leave you with any options; either you wrap every string assignment in try/catch blocks, or you just hope it works. Compare this with the following in C:char string1[80];
...
The above code can't possibly fail. There's no need for try/catch, or needless error checking - the destination array will always be large enough.char string2[40];
char string3[40];
strcat(string1,string2);
strcat(string1,string3);
I could go on about how my university taught students to allocate memory but not to free it, but I'll spare you. I think the real problem is that the illusion of infinite memory is just that - an illusion. While the String types have some nice features, everything done with a String type can be done with C-style strings, and if it can't, it's usually trivial to implement. With C-style strings, I can formally prove the correctness of an algorithm, but not with the String types, simply because their behavior is not well defined for cases in which memory allocation fails. Even if these string types had a standard behavior, you're still left with an algorithm that becomes useless when memory allocation fails.
And do you know for certain that the String type isn't immune to buffer overflow? If your program crashed because of excess input, would it escape back to a root-level shell? When it comes down to it, security requires more thought than just using some nifty-yet-formally-incomplete classes.