You don't *always* need to use sprintf(). Actually more often than not, I know the length of target string before sprintf()ing (especially when working with strings). snprintf is still handy, though.
While kind of cute, it's not strictly true. Arrays act as constant pointers in many respects, but there are some instances (most notably with the sizeof operator) where they act very different from pointers.
Hmm that's a good point. I suppose that's where a code checker would be much more useful than an interpreter, e.g. it can draw trees of which variables get where, where they get casted into what, etc. lclint is kind of a mess, but making a backend for gcc to do this sort of thing could be worthwhile.
I'll concede, though, that type-safe languages are well-suited for security-critical applications.
I think what you're describing is an office assistant that works for free. Your only hope is that somehow AI can be made more intelligent than your average office assistant.
Old archives (prior to 2000 it seems) are currently not existent on Deja. Anyway I don't see the problem with some GNU extensions and functions not being able to be disabled, maybe because I already have an understanding as to what's standard and what's not. Oh well.
Yes it was what I meant. I always thought "type safety" was kind of a continuum. There's complete type unsafety (perhaps not unlike machine language); there's complete type safety (of a language unknown to me), and then there's all that in between. In order to do inheritance and stuff like that in C, you have to use generic pointers, which means that your compiler can not easily (though it is still possible) to catch type errors. So in that respect, C++ is "type safer" than C is, though I agree it is definitely not completely safe.
People could very well start using segmentation again without so many horrors. The problem before was that the segments had a size of 64kB, whereas the total RAM was measured in the megabytes. With the 386, the address space of the segments was the same as the address space of the entire machine. So using segments isn't terribly different from just using straight pages. You need 15MB on the stack? Not really a big problem. Therefore, there should be no worries about changing segments all the time, because all your data is in one segment.
First of all, yes, C does have an array type. Arrays are not pointers, and pointers are not arrays. Arrays have a nasty habit of decaying on you, but the second you forget and treat them as pointers is the second you run into trouble.
From the view-point of dealing with stack smashes specifically, this can be helpful. Arrays, like any other statically or automatically allocated objects, are declared on the stack, whereas dynamically allocated "arrays" (the target of pointers usually) are declared on the heap. Of course getting rid of stack smashes isn't quite as interesting as getting rid of buffer overruns altogether (both stack smashes and "heap" smashes), but the difference can be useful.
As I mentioned in another post, though, you can interpret C as much as you want. There's no reason for a C implementation to have a compiler, and even a human being can (in silly situations) be considered a compliant implementation. If you interpret the hell out of it, so that for everreference to an object, you trace its history throughout the program, you can be fairly safe. It might take an hour just to go through a single instruction; "hello world" might take six years to run on the fastest Cray, but it will give you everything you ever wanted to know. Of course these are silly examples: usually C interpreters only slow things down by a magnitude of a few hundred times (or less) when compared to compiled code. But you only have to interpret once and get an "everything is OK" before you can take that same code, turn around, and compile it.
This is, of course, possible with other languages. There are political and legal obstacles with Java, I think. But for all complex languages (of which I'm saying C is not), making your own interpreter is too much trouble for such little reward.
First off, I think malloc()/free() debugging is grossly exaggerated. I had problems with it at first before I knew what was certain things in the language meant, and before I became familiar with my debugger.
C interpreters give something very valuable to C, though. You can make them as slow and bloated and pedantic as you like. Maybe they run 500x slower than compiled C code. All you have to do is run it through there once, though, before you can be assured (as assured as you can ever be when dealing with software) that it is safe, you can take the *exact* same code and compile it with a compiler. You get safety and performance: the best of both worlds. Mind you there aren't decent C interpreters available for every language:).
But anyway, in case you haven't guessed, I really like C. It's simple enough and such a widely supported language (arguably the first real cross-platform language, and it's only gained portably and acceptance since then) that you can do whatever you like with it without much trouble.
You have a very narrow view of "bugs". Remember the old system() bugs? I don't know if Java has a direct analogue to system(), but it would still be possible either way. I'm talking about logic errors, not "programmatic" (for lack of a better term) errors. Every language or standard library that allows you some control (e.g. all current programming languages that I'm aware of) is going to give you the possibility to grant crackers root.
No, you don't need to put in bounds checking manually. Bounds checking is a property of the *compiler*, not the *language*. There are many C interpreters (and even many C compilers) which will implement bounds checking.
True, the standard library isn't the only place where buffer overflows come about. A good code checker, though, should catch nearly everything (lclint does admittedly fall down in a few places).
It still comes down to the fact that the reason they're insecure is because whoever was writing them wrote bad code. This could be miscommunication between programmers, or the fact that one guy was hung over when he wrote it, or it could be that he just sucks ass at writing code. I don't think that bad Java code is any better than bad C code, though. You'd just end up with a different class of bugs.
Well to be fair, *all* of the features in C++ can be written in C. What you gain in C++ is type safety, which is a feature I think better left to language checkers, such as (but not necessarily) lint.
That said, the biggest problem I have with C++ is that Bjarne just wasn't satisfied with putting in object-oriented syntactic sugar, or even just the kitchen sink. It seems like every little feature that crossed his mind (or the mind of any of his friends) was put in there. I think he could learn a lot from the approach that Objective C used (Simula vs Smalltalk flamewars aside).
It is not the fault of the language; it is the fault of stupid people. Anybody with either: (a) skill, time, patience and experience; or (b) lclint will *not* have buffer overflows. Seriously, though, all you have to do is run your favourite program through lclint and it'll point them out to you: "buffer overflow possibility over there. Oh, there's another one".
You should be blaming the programmers from 10 years ago. The *only* C programs that I have seen that have one of: - gets() - scanf() - poor use of *scanf() or str*() are programs that have (a) been written 10 years ago; or (b) written by programmers who learned how to code in C 10 years ago. Yes, there are stupid technical school and high school teachers too, but normally, before anyone gets to a level where they can do something useful, they will have found a clueful reference to get rid of all that nonsense.
There is a new breed of C programmers, though. They don't assume Unicisms, PDPisms or TheirPlatformisms, and their eyes actually burn a whole through their skull upon the mere sight of gets(), scanf(), or any of the other death traps.
C is a good language. C++, of course, is not, though (hey, if you can get modded up for ignorant flamebait, why can't I?)
Uhh it's not as great as you make it out to be. All it does is shift responsibility from using a standard mail format into using a standard mail protocol. You gain network capabilities, which is nice, but that is all.
Themes support has nothing to do with whether one toolkit is "inferior" compared to another. Presumably many people consider QT's API to be "inferior" to GTK's. Having worked with GTK, I find that very hard tobelieve, but I suppose it is possible (mind you I think you'd have to be intentionally obtuse to create an API worse than GTK's). Plus, QT does not have a C binding AFAIK, which is very annoying.
You'll notice that there are never perfect analogies. Whenever you liken something in real life (vandalism, break and enter) to something in the computer world (document defacement, unauthorised access), you'll always have at least "except that" that comes up, as you have so graciously pointed out in your post. They are not perfect analogies.
I'll put my views of the justice system aside for a moment and just say that if they want to carry on the way they're going, looking at different types of crimes in a different light (and in different laws if need-be) is not a bad idea.
Genetic engineering is quite a bit different from breeding. If it weren't, they would be the same thing. Getting rid of the "heart disease gene" sounds like a good idea, but it's not exactly clear right now what will and what will not be affected by changing the gene. Changing that one gene without changing any others might cause some side effects. Or not. The problem is that genetic engineering as a science is so immature that nobody knows. At least breeding is a tried and proved method to get what you want (albeit with a lot of time and effort).
You have to remember that there were a lot of miracle sciences that came out earlier, especially just post-war, which promised great things for babies and mothers, but caused a lot more trouble. It's quite understandable for people to be more wary the second time around.
Million = 10^(6 * 1) Billion = 10^(6 * 2) (Bi = 2, get it?) Trillion = 10^(6 * 3) (Tri = 3)
etc. It's much more logical than the million = 10^6, billion = 10^9 system. I've never heard of the 'mi' prefix used anywhere else, but we can just pretend that's logical too.
Slashdot Mirror
You don't *always* need to use sprintf(). Actually more often than not, I know the length of target string before sprintf()ing (especially when working with strings). snprintf is still handy, though.
While kind of cute, it's not strictly true. Arrays act as constant pointers in many respects, but there are some instances (most notably with the sizeof operator) where they act very different from pointers.
Hmm that's a good point. I suppose that's where a code checker would be much more useful than an interpreter, e.g. it can draw trees of which variables get where, where they get casted into what, etc. lclint is kind of a mess, but making a backend for gcc to do this sort of thing could be worthwhile.
I'll concede, though, that type-safe languages are well-suited for security-critical applications.
I think what you're describing is an office assistant that works for free. Your only hope is that somehow AI can be made more intelligent than your average office assistant.
fgets
Old archives (prior to 2000 it seems) are currently not existent on Deja. Anyway I don't see the problem with some GNU extensions and functions not being able to be disabled, maybe because I already have an understanding as to what's standard and what's not. Oh well.
Yes it was what I meant. I always thought "type safety" was kind of a continuum. There's complete type unsafety (perhaps not unlike machine language); there's complete type safety (of a language unknown to me), and then there's all that in between. In order to do inheritance and stuff like that in C, you have to use generic pointers, which means that your compiler can not easily (though it is still possible) to catch type errors. So in that respect, C++ is "type safer" than C is, though I agree it is definitely not completely safe.
People could very well start using segmentation again without so many horrors. The problem before was that the segments had a size of 64kB, whereas the total RAM was measured in the megabytes. With the 386, the address space of the segments was the same as the address space of the entire machine. So using segments isn't terribly different from just using straight pages. You need 15MB on the stack? Not really a big problem. Therefore, there should be no worries about changing segments all the time, because all your data is in one segment.
First of all, yes, C does have an array type. Arrays are not pointers, and pointers are not arrays. Arrays have a nasty habit of decaying on you, but the second you forget and treat them as pointers is the second you run into trouble.
From the view-point of dealing with stack smashes specifically, this can be helpful. Arrays, like any other statically or automatically allocated objects, are declared on the stack, whereas dynamically allocated "arrays" (the target of pointers usually) are declared on the heap. Of course getting rid of stack smashes isn't quite as interesting as getting rid of buffer overruns altogether (both stack smashes and "heap" smashes), but the difference can be useful.
As I mentioned in another post, though, you can interpret C as much as you want. There's no reason for a C implementation to have a compiler, and even a human being can (in silly situations) be considered a compliant implementation. If you interpret the hell out of it, so that for everreference to an object, you trace its history throughout the program, you can be fairly safe. It might take an hour just to go through a single instruction; "hello world" might take six years to run on the fastest Cray, but it will give you everything you ever wanted to know. Of course these are silly examples: usually C interpreters only slow things down by a magnitude of a few hundred times (or less) when compared to compiled code. But you only have to interpret once and get an "everything is OK" before you can take that same code, turn around, and compile it.
This is, of course, possible with other languages. There are political and legal obstacles with Java, I think. But for all complex languages (of which I'm saying C is not), making your own interpreter is too much trouble for such little reward.
First off, I think malloc()/free() debugging is grossly exaggerated. I had problems with it at first before I knew what was certain things in the language meant, and before I became familiar with my debugger.
:).
C interpreters give something very valuable to C, though. You can make them as slow and bloated and pedantic as you like. Maybe they run 500x slower than compiled C code. All you have to do is run it through there once, though, before you can be assured (as assured as you can ever be when dealing with software) that it is safe, you can take the *exact* same code and compile it with a compiler. You get safety and performance: the best of both worlds. Mind you there aren't decent C interpreters available for every language
But anyway, in case you haven't guessed, I really like C. It's simple enough and such a widely supported language (arguably the first real cross-platform language, and it's only gained portably and acceptance since then) that you can do whatever you like with it without much trouble.
You have a very narrow view of "bugs". Remember the old system() bugs? I don't know if Java has a direct analogue to system(), but it would still be possible either way. I'm talking about logic errors, not "programmatic" (for lack of a better term) errors. Every language or standard library that allows you some control (e.g. all current programming languages that I'm aware of) is going to give you the possibility to grant crackers root.
No, you don't need to put in bounds checking manually. Bounds checking is a property of the *compiler*, not the *language*. There are many C interpreters (and even many C compilers) which will implement bounds checking.
True, the standard library isn't the only place where buffer overflows come about. A good code checker, though, should catch nearly everything (lclint does admittedly fall down in a few places).
It still comes down to the fact that the reason they're insecure is because whoever was writing them wrote bad code. This could be miscommunication between programmers, or the fact that one guy was hung over when he wrote it, or it could be that he just sucks ass at writing code. I don't think that bad Java code is any better than bad C code, though. You'd just end up with a different class of bugs.
Well to be fair, *all* of the features in C++ can be written in C. What you gain in C++ is type safety, which is a feature I think better left to language checkers, such as (but not necessarily) lint.
That said, the biggest problem I have with C++ is that Bjarne just wasn't satisfied with putting in object-oriented syntactic sugar, or even just the kitchen sink. It seems like every little feature that crossed his mind (or the mind of any of his friends) was put in there. I think he could learn a lot from the approach that Objective C used (Simula vs Smalltalk flamewars aside).
It is not the fault of the language; it is the fault of stupid people. Anybody with either: (a) skill, time, patience and experience; or (b) lclint will *not* have buffer overflows. Seriously, though, all you have to do is run your favourite program through lclint and it'll point them out to you: "buffer overflow possibility over there. Oh, there's another one".
You should be blaming the programmers from 10 years ago. The *only* C programs that I have seen that have one of:
- gets()
- scanf()
- poor use of *scanf() or str*()
are programs that have (a) been written 10 years ago; or (b) written by programmers who learned how to code in C 10 years ago. Yes, there are stupid technical school and high school teachers too, but normally, before anyone gets to a level where they can do something useful, they will have found a clueful reference to get rid of all that nonsense.
There is a new breed of C programmers, though. They don't assume Unicisms, PDPisms or TheirPlatformisms, and their eyes actually burn a whole through their skull upon the mere sight of gets(), scanf(), or any of the other death traps.
C is a good language. C++, of course, is not, though (hey, if you can get modded up for ignorant flamebait, why can't I?)
Uhh it's not as great as you make it out to be. All it does is shift responsibility from using a standard mail format into using a standard mail protocol. You gain network capabilities, which is nice, but that is all.
You're against the idea of companies taking advantage of the weak and stupid? If I'm not mistaken, that's the very definition of capitalism.
Use less -r, brainiac.
Your question is frequently asked. Hence, it is in the Slashdot FAQ.
Themes support has nothing to do with whether one toolkit is "inferior" compared to another. Presumably many people consider QT's API to be "inferior" to GTK's. Having worked with GTK, I find that very hard tobelieve, but I suppose it is possible (mind you I think you'd have to be intentionally obtuse to create an API worse than GTK's). Plus, QT does not have a C binding AFAIK, which is very annoying.
You'll notice that there are never perfect analogies. Whenever you liken something in real life (vandalism, break and enter) to something in the computer world (document defacement, unauthorised access), you'll always have at least "except that" that comes up, as you have so graciously pointed out in your post. They are not perfect analogies.
I'll put my views of the justice system aside for a moment and just say that if they want to carry on the way they're going, looking at different types of crimes in a different light (and in different laws if need-be) is not a bad idea.
Genetic engineering is quite a bit different from breeding. If it weren't, they would be the same thing. Getting rid of the "heart disease gene" sounds like a good idea, but it's not exactly clear right now what will and what will not be affected by changing the gene. Changing that one gene without changing any others might cause some side effects. Or not. The problem is that genetic engineering as a science is so immature that nobody knows. At least breeding is a tried and proved method to get what you want (albeit with a lot of time and effort).
You have to remember that there were a lot of miracle sciences that came out earlier, especially just post-war, which promised great things for babies and mothers, but caused a lot more trouble. It's quite understandable for people to be more wary the second time around.
Use an unstable branch then?
Yes, apparently. The Quakes run just as well on FreeBSD as they do on Linux.
They go by 10^6.
Million = 10^(6 * 1)
Billion = 10^(6 * 2) (Bi = 2, get it?)
Trillion = 10^(6 * 3) (Tri = 3)
etc. It's much more logical than the million = 10^6, billion = 10^9 system. I've never heard of the 'mi' prefix used anywhere else, but we can just pretend that's logical too.