Perhaps if you knew how to properly use a decimal place and a comma there'd be a website outside of the United States worth a damn that someone might want to visit.
The next time Slashdot links to a BBC story like they do several times a week, I take it then you won't be reading it?
The chief argument against a lot of attempts to make content carriers censor their users' content has often been that the carrier of the content can't be held accountable for content because it order to be held accountable, it would have to evesdrop on all messages, and that's not allowed. Now that it *is* allowed, I fear more for what might happen to this argument against censorship. Once it is *allowed* that a content carrier can read your messages, there's going to be cases where they get sued over things people have said in their messages, and suddenly they're going to have to censor just to cover their own butt from lawsuits.
If someone opens your snail mail to read it, they have to tamper with the envelope. It leaves evidence behind. They can read e-mail without disrupting service or doing anything that would make anyone realize it is happening.
The process you describe, of licensing out a patented idea to others to use, does not fit under the description of the parent poster, of patenting something and just sitting on it, so it's obviously not what he/she was talking about.
European countries use the dot to separate thousands and the comma to start the decimal fraction, exactly the inverse of what we Americans do. Take off the blinders and try living in the larger world.
if the company should be going after anyone, it's the person who created the code
Yeah, but in the general case, they don't actually *know* who within Google is at fault. Legally, they have to view the company as a black box. On the outside, they can only notice the final result. They have no idea how that final result got the way it is. For example, did the programmer tell Google where his idea was coming from? If so, then Google would definately be responsible. Otherwise they wouldn't. Did someone higher up in the management structure direct him to make the software based on his previous company's software, or did he do it on his own initiative? These sorts of questions are what makes it so that you have to sue the company, not the individual. If it is entirely the employee's fault, and he kept google in the dark about what he was really doing, then the company can turn around and sue the employee for fraud, as a second case, to recoup their losses.
One problem is that what the programmers' employers attempt to claim ownership of in employment contracts is so clearly obviously legally unenforcable that you (the programmer) are left having no clue what knowlege you can actually take with you when you switch jobs. Since the employment contract makes claims on EVERYTHING YOU EVER THINK OF while employed by that company, and you know this isn't *really* what they can legally lay claim to, you are left having to guess where the border actually is bewtween ideas you own and ideas your company owns. More than likely in this case, the Google programmer just guessed incorrectly where that border is.
I do hope they settle this politely out of court, in the friendly understanding that it wasn't deliberately malicious.
You must have missed the part where the poster pointed out that lesser jurisdictional law enforcement agencies weren't allowed to handle the problem because it crossed state lines - The poster DID try those first, and they passed the buck upward to the FBI. So by saying the poster shouldn't bother the FBI over this, you are simultaneously telling the poster there exists NO law enforcement agency that can be used, so just suck it up and take the $1000 hit.
Nah, there is nothing illegal about making a product that is insecure. The illegal, and unethical thing, is when you lie to your customers about what your product can and can't do. What we really need isn't government mandates telling software companies exactly what type of software they must make. What we need is enforcement of the rules that were allegedly supposed to make advertisements have to be truthful, but they don't because they are never enforced. That would kill Microsoft right there, without establishing any dangerous draconian precidents about mandating what kind of software a company must make.
There's nothing wrong with making insecure software, provided your customers KNOW that you weren't bothering with security as a goal, and they don't mind that that's what they're getting.
And furthermore, even if they do know what it means and have the sense to turn it off, they have to have the intuition to look at that dialog panel to even be aware that such a thing exists. When you first run a program, is the first thing you do to go around looking at all the various File|Preferences and Tools|Options panels, and look over every single tab searching for stupid settings under the assumption that the defaults will be dangerous to use? Probably not.
Detonation, which is what an explosive does, is defined as supersonic flame travel.
The post in question, with which I took exception, called gasoline an explosive. It was clearly therefore NOT using that definition of "explosive", since gasoline vapors catching fire do not do so at supersonic speed. It's fast, I'll grant that, but not that fast.
All you would need is to replace my simple if test with a multi switch case statement to achieve the same effect.
No, that is still the same problem. If each case has exactly one malloc, the compiler can still detect that. To make the compiler unable to count the mallocs without running the code "in it's head", you need something where the malloc could be run N times, where N is determined at runtime. A multi switch case statement is still just another way of writing an if-else ladder - it always jumps forward, never backward, and there are a finite number of countable passes through each section, either zero passes, or one pass.
But the problem is that since C++ programs can also make calls to the C library, programmers often end up doing that instead of using the C++ features, *especially* with regards to string manipulations. While this might seem like the fault of bad programmers, keep in mind that the string manipulation abilities of C, while insecure, are very, very powerful. Also, for the longest time, the output formatting abilities of C++ were horrible. Even today, while they can do everything that the stdio libraries can do, they still take five times as much verbiage to do it. There's something to be said for: printf( "%12.2lf", balance );
If the makers of C++ had wanted to get rid of the unsafe use of null-terminated strings, they should have included a FULLY FEATURED string manipulation and string output facility that was just as easy if not easier to use than the one that you could use in old-fashioned C. Because they didn't (at first), they created a dis-incentive for dropping c-style strings.
Actually, it's only supposed to issue you that warning if there really does exist a scenario where you are trying to use that variable after the if/else, and in that case, it really *IS* a problem. Consider:
// This function should compile okay without error: void someFunc(void) {
int x,i;
if( foo ) {
x = 5;
}
else {
return;
}
for( i = 0 ; i < x ; i++ ) { // do something
} } // This version of the function should give an uninitialization error: void someFuncOops(void) {
int x,i;
if( foo ) {
x = 5;
}
else { // nothing - forgot the 'return'.
} // the next line is an error. 'i < x' is testing against an // uninitialized 'x' if the 'else' was used above.
for( i = 0 ; i < x ; i++ ) { // do something
} }
The error you get from this is NOT supposed to be on the if/else lines. It's on the 'for' line. It's telling you the compiler found a path through the code where it *could* reach that attempt to use the variable and it hasn't been initialized yet.
If the condition you are referring to does happen, then it means your compiler is broken. It shouldn't even be issuing a warning either.
Your sentiment is correct, but that's a poor example, that doesn't really demonstrate the problem. A compiler could still follow your if/else ladder and detect that no matter what the condition is, exactly one instance of the malloc call will be made, and thus the one free call is correct. Consider - this is kind of what happens when a compiler complains that a line can be reached while a variable is uninitialized.
A better example is this. Consider the following code:
int x; int i; char **strings;
x = 5; strings = calloc( x, sizeof(char*) ); // Make some 100-character strings: for( i = 0 ; i < x ; i++ ) { strings[i] = calloc( 100, sizeof(char) ) ); }
// do some stuff with the strings (not shown)
// commented-out line: // x = x - 1;
// Free the strings: for( i = 0 ; i < x ; i++ ) { free( strings[i] ); } free( strings );
That code works without orphaning memory.
But now, consider modifying the above example so that the 'x = x - 1' line is uncommented. Then what would happen. Then there'd be 5 allocations, but only 4 frees.
Trying to write a compiler that can detect the difference between those two cases, with regard to counting the allocs and frees, is essentially a restatement of the halting problem, and cannot be done. The only way to detect that the change to the x variable is important to the orphaning of memory, is for the compiler to go through and examine every statemnt of the code and think "hypothetically, what would happen if I ran this statement?", and at that point the compiler ceases to be a compiler and becomes an interpreter, and thus has the same memory orphaning problem that the code itself has.
If I write a C program that makes 5 malloc() and 4 free(), the compiler should notice that
That's NOT possible in the slightest. If it was that simple. programmers would be able to avoid memory leaks with ease. Consider that you often malloc in a loop, and free in a loop. Now, how does your compiler detect that the mallocing loop will run 5 times while the freeing loop will only run 4 times? There are proofs in computer science that essentially end up saying that the only way a program can read another program's code and find out how many times a loop will run, is to actually end up becoming an interpreter itself, and actually RUN that code as it is written.
The fact that you can't solve the halting problem at compile time also means you can't solve the memory orphaning problem at compile time. The only way to match up the number of mallocs to the number of frees is to do it at runtime, which is why garbage collecting languages were invented.
The lesson people need to learn is that with any large project you should identify *where* security is more important than speed, and in those places use the languages that sacrifice speed for security, but in other places, still leave open the ability to use the faster language. Your comments about pointer arithmetic being evil, and arrays without bounds checking being evil, are true when avoiding overflows is the most important thing. But they're not true when speed is the most important thing. If you're developing a web application that does a lot of math on big in-memory structures, for example, and you notice that it's running slow, then keep the input parsing part in Java, and after security checking the input, pass the input off to a C program to do the actual work, and use the Java program to pick up the results of the C program and show them back to the user.
Basicly, any time you are taking user input or showing user output, security is so important that the efficiency or speed can be completely ignored. Generally, those aren't the areas where the speed bottleneck is anyway, so it doesn't matter if they are slow.
But don't throw out the baby with the bathwater. Speed does have it's uses. The problem with array bounds checking is that, when the program is working right, it serves no purpose but to waste time. It's there precisely to catch the case where the code is broken, but it "penalizes" all code all the time, even the non-broken code.
What about the situation where you build under multiple compilers and they can't agree on things? Sometimes it's literally impossible to get rid of all the warnings.
Besides, the habit of ignoring warnings often dates back to the days when the compiler was dumber than it is today and would complain about things that were 100% correct, like thinking you need to cast when comparing a typed pointer to a void pointer in C (they whole fscking reason void pointers were invented was precisely for situations in which you *don't* have to care what the type is. That's what they're FOR. Then dumb compilers kept yelling at you for not casting void pointers, leading to such uglifications as this:
if( a_string != (char*)NULL )...
Or, when a function is declared to take a void pointer, like:
free( void *m ); and the compiler would sometimes complain and bitch about not casting pointers when calling it.
This led to a practice that was even WORSE than leaving the warnings in place: Programmers being in the habit of casting *everywhere*, unthinkingly, to get the compiler to shut up. I even worked one place where this was the mandatory standard. I tried pointing out how bad a practice this is, because then the compiler will never tell you about actual ERRORS in mismatched types either - every time you use the wrong type of pointer, the compiler will assume you know about it and are doing it on purpose, because that's what you're trying to tell it by casting the pointer, so it won't raise an error.
This might sound like ancient history, like it doesn't matter, but often it's the case that this kind of thing is the reason many warnings are still there in old code, and new projects still use an awful lot of old code in them.
Sometimes the only response to a warning that works is to say, "Yes, I know what you're trying to tell me mister compiler, but in this case, you're wrong. No, that variable isn't uninitialized, it's just getting initialized somewhere you aren't noticing it. Yes, I know that variable is unused, but that's only because there's a section that only compiles when DEBUG is ifdef'ed on, and that's the section that still uses it.
People who repeat that phrase are typically trying to imply the converse, that anyone blaming his tools must be doing so because he is a bad workman. This is only true in the case where the workman got to pick his tools himself. The whole point of the expression, when it was originally coined, was that picking good tools to use is still part of the responsibility of the good workman, so he's got no right to complain about having bad tools - even if he has bad tools it's still his fault anyway. The problem is that ignoramuses keep trying to use this expression to refer to the software industry while ignoring the fact that in the software industry, the "workman" that they are referring to rarely gets to pick his own tools, and so the analogy completely fails on that point.
In the case of a school course, it *is* a valid complaint to point out that a stated given was a lie, and that's why the program doesn't work. If the givens say your program has to take a list of up to 1000 items, and the test data contains 2000 items, then that is a legitimate reason for the student to complain. Also, if the code was supposed to handle an unusually large amount of data, and making the structure efficient is a requirement, then there must be stated goals to shoot for since every machine differs. (i.e. your program must be able to handle up to 500,000 rows of data, and run in less than 30 meg of RAM.)
Given how much work typically goes into making code able to robustly handle every single type of user input, it is unreasonable to expect students to finish five or six such programs during a three credit course while also doing other classwork, *especially* when code is typically supposed NOT re-used between assignments. To say otherwise is to make the student spend 95% of his time on something that has nothing to do with the lessons, and is the *same* thing over and over in every class. The reason they use givens that let students get away with less than robust programs is for the same reason that they let students use calculators in higher level math classes - It relieves drudgery and gets down to the point being studied.
Any school curriculum worth anything will *also* have one course in which you learn nothing new, theory-wise, and instead concentrate the whole semester on working as a team on a project and dealing with all the real-world problems you tend to gloss over the rest of the time in other classes - things like how you test, how you make specifications, how you break the task into parts, and all of that. It's often called "Software Engineering", but I hate that title. It's actually software management.
When you're in college, the graders are not trying to break into your application, they're just evaluating the source code and give you points for correct stack and linked list implementation.
Part of the definition of "correct stack and linked list implementation" *includes* handling the tough cases that are likely to break the implementation. If they aren't checking that, then they aren't actually checking for correct implemention. What happens when you keep deleting and re-adding the same node over and over? What happens when you empty the structure altogether and rebuild it. Inserting at the start, middle, and end - how do those hold up? Can it do tens of thousands of inserts, then tens of thousands of deletes, and not end up orphaning memory? When I was in college, these were the kinds of things the test data the graders used would cover.
The paradigm of storing data on punch cards is largely responsible for why dates were stored as individual columns.
I have a hard time believing that because I doubt the majority of the software that had to be fixed for the year 2000 was actually using punchcards. For example, I doubt that an IBM PC uses punchcards in it's Bios clock. Also, I worked on a system that had inherited the "punchcard" thinking and transferred records as fixed-column text files, and referred to each line of the file as a "card" even though it was stored electronically. And even that system didn't use 80 character limits anymore. The things they called "cards" were hundreds of characters "wide". They certainly didn't think of them in terms of 80 character chunks anymore. And I have a hard time believing many other places still did either. I have no doubt that *some* systems somewhere had still been doing it that way, but certainly not the majority of the ones that needed fixing.
Slashdot Mirror
Was this an attempt at sarcasm? It failed. To be sarcasm you have to exaggerate, instead of saying reasonable, true things.
Perhaps if you knew how to properly use a decimal place and a comma there'd be a website outside of the United States worth a damn that someone might want to visit.
The next time Slashdot links to a BBC story like they do several times a week, I take it then you won't be reading it?
The chief argument against a lot of attempts to make content carriers censor their users' content has often been that the carrier of the content can't be held accountable for content because it order to be held accountable, it would have to evesdrop on all messages, and that's not allowed. Now that it *is* allowed, I fear more for what might happen to this argument against censorship. Once it is *allowed* that a content carrier can read your messages, there's going to be cases where they get sued over things people have said in their messages, and suddenly they're going to have to censor just to cover their own butt from lawsuits.
If someone opens your snail mail to read it, they have to tamper with the envelope. It leaves evidence behind. They can read e-mail without disrupting service or doing anything that would make anyone realize it is happening.
The process you describe, of licensing out a patented idea to others to use, does not fit under the description of the parent poster, of patenting something and just sitting on it, so it's obviously not what he/she was talking about.
European countries use the dot to separate thousands and the comma to start the decimal fraction, exactly the inverse of what we Americans do. Take off the blinders and try living in the larger world.
if the company should be going after anyone, it's the person who created the code
Yeah, but in the general case, they don't actually *know* who within Google is at fault. Legally, they have to view the company as a black box. On the outside, they can only notice the final result. They have no idea how that final result got the way it is. For example, did the programmer tell Google where his idea was coming from? If so, then Google would definately be responsible. Otherwise they wouldn't. Did someone higher up in the management structure direct him to make the software based on his previous company's software, or did he do it on his own initiative? These sorts of questions are what makes it so that you have to sue the company, not the individual. If it is entirely the employee's fault, and he kept google in the dark about what he was really doing, then the company can turn around and sue the employee for fraud, as a second case, to recoup their losses.
One problem is that what the programmers' employers attempt to claim ownership of in employment contracts is so clearly obviously legally unenforcable that you (the programmer) are left having no clue what knowlege you can actually take with you when you switch jobs. Since the employment contract makes claims on EVERYTHING YOU EVER THINK OF while employed by that company, and you know this isn't *really* what they can legally lay claim to, you are left having to guess where the border actually is bewtween ideas you own and ideas your company owns. More than likely in this case, the Google programmer just guessed incorrectly where that border is.
I do hope they settle this politely out of court, in the friendly understanding that it wasn't deliberately malicious.
You must have missed the part where the poster pointed out that lesser jurisdictional law enforcement agencies weren't allowed to handle the problem because it crossed state lines - The poster DID try those first, and they passed the buck upward to the FBI. So by saying the poster shouldn't bother the FBI over this, you are simultaneously telling the poster there exists NO law enforcement agency that can be used, so just suck it up and take the $1000 hit.
Nah, there is nothing illegal about making a product that is insecure. The illegal, and unethical thing, is when you lie to your customers about what your product can and can't do. What we really need isn't government mandates telling software companies exactly what type of software they must make. What we need is enforcement of the rules that were allegedly supposed to make advertisements have to be truthful, but they don't because they are never enforced. That would kill Microsoft right there, without establishing any dangerous draconian precidents about mandating what kind of software a company must make.
There's nothing wrong with making insecure software, provided your customers KNOW that you weren't bothering with security as a goal, and they don't mind that that's what they're getting.
And furthermore, even if they do know what it means and have the sense to turn it off, they have to have the intuition to look at that dialog panel to even be aware that such a thing exists. When you first run a program, is the first thing you do to go around looking at all the various File|Preferences and Tools|Options panels, and look over every single tab searching for stupid settings under the assumption that the defaults will be dangerous to use? Probably not.
Detonation, which is what an explosive does, is defined as supersonic flame travel.
The post in question, with which I took exception, called gasoline an explosive. It was clearly therefore NOT using that definition of "explosive", since gasoline vapors catching fire do not do so at supersonic speed. It's fast, I'll grant that, but not that fast.
All you would need is to replace my simple if test with a multi switch case statement to achieve the same effect.
No, that is still the same problem. If each case has exactly one malloc, the compiler can still detect that. To make the compiler unable to count the mallocs without running the code "in it's head", you need something where the malloc could be run N times, where N is determined at runtime. A multi switch case statement is still just another way of writing an if-else ladder - it always jumps forward, never backward, and there are a finite number of countable passes through each section, either zero passes, or one pass.
I argued that compilers are smart enough to analyze the code and find out which places need bounds checks etc
No, they're not that smart. About the only case they can drop the checks for is the case where you are using a literal as the array index.
But the problem is that since C++ programs can also make calls to the C library, programmers often end up doing that instead of using the C++ features, *especially* with regards to string manipulations. While this might seem like the fault of bad programmers, keep in mind that the string manipulation abilities of C, while insecure, are very, very powerful. Also, for the longest time, the output formatting abilities of C++ were horrible. Even today, while they can do everything that the stdio libraries can do, they still take five times as much verbiage to do it. There's something to be said for: printf( "%12.2lf", balance );
If the makers of C++ had wanted to get rid of the unsafe use of null-terminated strings, they should have included a FULLY FEATURED string manipulation and string output facility that was just as easy if not easier to use than the one that you could use in old-fashioned C. Because they didn't (at first), they created a dis-incentive for dropping c-style strings.
If the condition you are referring to does happen, then it means your compiler is broken. It shouldn't even be issuing a warning either.
A better example is this. Consider the following code:That code works without orphaning memory.
But now, consider modifying the above example so that the 'x = x - 1' line is uncommented. Then what would happen. Then there'd be 5 allocations, but only 4 frees.
Trying to write a compiler that can detect the difference between those two cases, with regard to counting the allocs and frees, is essentially a restatement of the halting problem, and cannot be done. The only way to detect that the change to the x variable is important to the orphaning of memory, is for the compiler to go through and examine every statemnt of the code and think "hypothetically, what would happen if I ran this statement?", and at that point the compiler ceases to be a compiler and becomes an interpreter, and thus has the same memory orphaning problem that the code itself has.
If I write a C program that makes 5 malloc() and 4 free(), the compiler should notice that
That's NOT possible in the slightest. If it was that simple. programmers would be able to avoid memory leaks with ease. Consider that you often malloc in a loop, and free in a loop. Now, how does your compiler detect that the mallocing loop will run 5 times while the freeing loop will only run 4 times? There are proofs in computer science that essentially end up saying that the only way a program can read another program's code and find out how many times a loop will run, is to actually end up becoming an interpreter itself, and actually RUN that code as it is written.
The fact that you can't solve the halting problem at compile time also means you can't solve the memory orphaning problem at compile time. The only way to match up the number of mallocs to the number of frees is to do it at runtime, which is why garbage collecting languages were invented.
The lesson people need to learn is that with any large project you should identify *where* security is more important than speed, and in those places use the languages that sacrifice speed for security, but in other places, still leave open the ability to use the faster language. Your comments about pointer arithmetic being evil, and arrays without bounds checking being evil, are true when avoiding overflows is the most important thing. But they're not true when speed is the most important thing. If you're developing a web application that does a lot of math on big in-memory structures, for example, and you notice that it's running slow, then keep the input parsing part in Java, and after security checking the input, pass the input off to a C program to do the actual work, and use the Java program to pick up the results of the C program and show them back to the user.
Basicly, any time you are taking user input or showing user output, security is so important that the efficiency or speed can be completely ignored. Generally, those aren't the areas where the speed bottleneck is anyway, so it doesn't matter if they are slow.
But don't throw out the baby with the bathwater. Speed does have it's uses. The problem with array bounds checking is that, when the program is working right, it serves no purpose but to waste time. It's there precisely to catch the case where the code is broken, but it "penalizes" all code all the time, even the non-broken code.
What about the situation where you build under multiple compilers and they can't agree on things? Sometimes it's literally impossible to get rid of all the warnings.
...
Besides, the habit of ignoring warnings often dates back to the days when the compiler was dumber than it is today and would complain about things that were 100% correct, like thinking you need to cast when
comparing a typed pointer to a void pointer in C (they whole fscking reason void pointers were invented was precisely for situations in which you *don't* have to care what the type is. That's what they're FOR. Then dumb compilers kept yelling at you for not casting void pointers, leading to such uglifications as this:
if( a_string != (char*)NULL )
Or, when a function is declared to take a void pointer, like:
free( void *m );
and the compiler would sometimes complain and bitch about not casting pointers when calling it.
This led to a practice that was even WORSE than leaving the warnings in place: Programmers being in the habit of casting *everywhere*, unthinkingly, to get the compiler to shut up. I even worked one place where this was the mandatory standard. I tried pointing out how bad a practice this is, because then the compiler will never tell you about actual ERRORS in mismatched types either - every time you use the wrong type of pointer, the compiler will assume you know about it and are doing it on purpose, because that's what you're trying to tell it by casting the pointer, so it won't raise an error.
This might sound like ancient history, like it doesn't matter, but often it's the case that this kind of thing is the reason many warnings are still there in old code, and new projects still use an awful lot of old code in them.
Sometimes the only response to a warning that works is to say, "Yes, I know what you're trying to tell me mister compiler, but in this case, you're wrong. No, that variable isn't uninitialized, it's just getting initialized somewhere you aren't noticing it. Yes, I know that variable is unused, but that's only because there's a section that only compiles when DEBUG is ifdef'ed on, and that's the section that still uses it.
People who repeat that phrase are typically trying to imply the converse, that anyone blaming his tools must be doing so because he is a bad workman. This is only true in the case where the workman got to pick his tools himself. The whole point of the expression, when it was originally coined, was that picking good tools to use is still part of the responsibility of the good workman, so he's got no right to complain about having bad tools - even if he has bad tools it's still his fault anyway. The problem is that ignoramuses keep trying to use this expression to refer to the software industry while ignoring the fact that in the software industry, the "workman" that they are referring to rarely gets to pick his own tools, and so the analogy completely fails on that point.
In the case of a school course, it *is* a valid complaint to point out that a stated given was a lie, and that's why the program doesn't work. If the givens say your program has to take a list of up to 1000 items, and the test data contains 2000 items, then that is a legitimate reason for the student to complain. Also, if the code was supposed to handle an unusually large amount of data, and making the structure efficient is a requirement, then there must be stated goals to shoot for since every machine differs. (i.e. your program must be able to handle up to 500,000 rows of data, and run in less than 30 meg of RAM.)
Given how much work typically goes into making code able to robustly handle every single type of user input, it is unreasonable to expect students to finish five or six such programs during a three credit course while also doing other classwork, *especially* when code is typically supposed NOT re-used between assignments. To say otherwise is to make the student spend 95% of his time on something that has nothing to do with the lessons, and is the *same* thing over and over in every class. The reason they use givens that let students get away with less than robust programs is for the same reason that they let students use calculators in higher level math classes - It relieves drudgery and gets down to the point being studied.
Any school curriculum worth anything will *also* have one course in which you learn nothing new, theory-wise, and instead concentrate the whole semester on working as a team on a project and dealing with all the real-world problems you tend to gloss over the rest of the time in other classes - things like how you test, how you make specifications, how you break the task into parts, and all of that. It's often called "Software Engineering", but I hate that title. It's actually software management.
When you're in college, the graders are not trying to break into your application, they're just evaluating the source code and give you points for correct stack and linked list implementation.
Part of the definition of "correct stack and linked list implementation" *includes* handling the tough cases that are likely to break the implementation. If they aren't checking that, then they aren't actually checking for correct implemention. What happens when you keep deleting and re-adding the same node over and over? What happens when you empty the structure altogether and rebuild it. Inserting at the start, middle, and end - how do those hold up? Can it do tens of thousands of inserts, then tens of thousands of deletes, and not end up orphaning memory? When I was in college, these were the kinds of things the test data the graders used would cover.
I'd blame the slow JVM startup time for that one.
Buggy JVM's were a bigger problem. Turning off Java in your browser was often necessary to keep the browser from crashing, or orphaning memory.
The paradigm of storing data on punch cards is largely responsible for why dates were stored as individual columns.
I have a hard time believing that because I doubt the majority of the software that had to be fixed for the year 2000 was actually using punchcards. For example, I doubt that an IBM PC uses punchcards in it's Bios clock. Also, I worked on a system that had inherited the "punchcard" thinking and transferred records as fixed-column text files, and referred to each line of the file as a "card" even though it was stored electronically. And even that system didn't use 80 character limits anymore. The things they called "cards" were hundreds of characters "wide". They certainly didn't think of them in terms of 80 character chunks anymore. And I have a hard time believing many other places still did either. I have no doubt that *some* systems somewhere had still been doing it that way, but certainly not the majority of the ones that needed fixing.