A language holy war isn't justified, but neither should we ignore the simple fact that almost all buffer overflows happen in C or other relatively low-level languages, and almost none in higher-level languages. Yes, you can program safely in C, and you can program unsafely in Ada if you choose to. (In C++ you can do both with equal ease.) But there's something to be said for a language that makes it simple to do the right thing, and requires a bit more explicitness and verbosity to do the wrong thing. With C it is often the opposite.
Actually, I wouldn't blame C so much as the standard library. If there were a decent set of variable-sized array classes, safe string classes and so on included as part of the standard C library, we probably wouldn't see so many problems.
Microsoft's security holes are another issue altogether and often related to 'active content' and other moronic ideas. Language wars certainly aren't relevant there.
Well in programming there isn't really an equivalent of particular components being below spec; either a program has a bug or it doesn't, and every copy of that program has the same behaviour. It's not as if one in every 1000 compilations of GNU Hello come out defective.
What you can do is defensive programming, so that even if some other code is buggy your program tries to stagger on rather than crash. But this is really difficult - where do you draw the line? If a function is specified as adding two numbers, should the caller also check that the numbers have been added correctly? If so you are just rewriting the code yourself. At best you can put in checks for a few obvious things like returning null when the specification says not-null, but in many programming languages (C++ with references, C with splint, Nice) this can be enforced by the compiler so a run-time check isn't needed.
Not quite the same: a fixed-length buffer is where you _know_ there is a bug - you know the program will crash or do weird things when given a too-long input. Not having buffer overflows is not part of any advanced fault-tolerant strategy; it's just the basic discipline of not releasing code you know is buggy.
Much more interesting is how to code for robustness in the face of bugs you _don't_ know about. That is very tricky, although encapsulating access to data structures so they're always in a sane state can help, also adding sanity checking, checked invariants and assertions (if you feel it safer to abort the program than continue).
In the short term the ISPs need to keep spam off their network. In the longer term, once nobody seems spam any more (because their ISP or mail client has filtered it out, based on trusted senders or micropayments or hash cash or whatever), spammers will no longer make money and will stop spamming.
Actually, I'd reckon that ISPs will move to a model where large users pay by the bit (many already do), so spam is not really their problem: it's the spamming ISP that foots the bill.
I'm an MEng and I've still written programs that crash... so have you. It's not a question of certification but just how much time you're prepared to take writing some code (by which I include choice of method, programming language and so on) and testing it. You can have thirty years of experience and still bang out flaky code if you're in a hurry. And if flaky code is all that's needed for the particular task, why not?
Rather than regulation we should let the market decide. Vendors could undertake: I will pay you $100 for each crash. Sometimes this already happens, eg with guarantees about the number of nines in server systems. The biggest problem is deciding responsibility for any faults. If an operating system call, which (according to POSIX or whatever) should not return null, one day does return null and the application crashes, who should pay up? And how do you find out whose fault it was? Running the whole system in some kind of virtual machine where you can roll back the last few seconds of execution would be one answer.
I'd hardly call it end-to-end. Here we have the mail server poking its nose into what type of mail is being delivered. It would make more sense for the mail system to get out of the way, deliver the messages, and let the users decide what they want to receive. Nobody advocates that IP routers should inspect each packet to see if it contains spam.
However, authenticated connection for mail delivery might not be a bad idea anyway, to stop DoS attacks based on sending millions of messages - even if all those are rejected by the recipient it still clogs the network, and unlike spammers, DoSers aren't trying to make money but just to cause a nuisance.
Apparently the main point of AMTP is to make it harder to spoof addresses. But it's still possible, so I don't think AMTP will change the general rule that no message header is to be trusted. PGP signatures blah blah blah are the only way to make sure a message comes from who it claims to.
Despite having Internet access at the time, I never heard of the Dancing Baby until it was mentioned on Ally McBeal (which I do not watch) or included on some crappy cover CD.
As far as I can tell it was a Windows executable which people sent to each other, and which when run displayed an animation of... a dancing baby.
Now unquestioningly running executables that people send you is not a good practice. But the Dancing Baby would encourage people to get into this bad habit because otherwise... well, you don't get to see the baby.
So it could be argued that the DB messages are indirectly responsible for Sobig and other worms.
The article says that the competition is to implement the System.Windows.Forms libraries. But I thought Miguel was doing some work to use Wine to implement this, since System.Windows.Forms (in true Microsoft style) is just a thin wrapper around the Win32 API.
Oh wait, that's Mono, not dotgnu. But why can't dotgnu do the same thing?
Or the other work that Mono is doing, a pure C# implementation of System.Windows.Forms using GTK#, why can't dotgnu use that? I thought this.net stuff was meant to be portable and compatible and stuff?
I don't understand why on Slashdot, the main application of any display improvement is automatically assumed to be the latest skin for GTK or kewl Enlightenment theme. Eye candy is about the least important thing in a desktop.
If what you say is true, and SCO (Calderuman) itself would not get most of the money, then either investors are too stupid to realize this, or the current stock price represents a market view that SCO are quite likely to win.
I believe the post you refer to is an attempt to test the metamoderation system by posting knowledgeable-sounding nonsense. For example, a hardware decoder cannot 'fractalize regions' - that would be something to do in the *encoder* and it would require support in the file format.
Myself I metamoderated as neither Fair nor Unfair, though if I had spotted the 'are you watching this?' signature before hitting submit I might have taken a closer look.
One reason to buy SCO stock is to hedge against them winning.
Suppose SCO is demanding $100 per Linux server, and you have 10 such servers. Then if they win you will need to find $1000. If SCO's stock price currently reflects a 5% chance of them winning, then any stock you do buy will increase 19-fold in value if they win. Therefore you need to buy $1000/19 worth of SCO stock to hedge against the risk. Of course you'd do this only if you think the 5% estimation by the market is about right, or too low - or if you think it's a bit too high but you're risk-averse.
If SCO wins, your stock should appreciate in value enough to cover the protection money you have to pay. If SCO lose, you've wasted about $52 on their now-worthless stock.
It's well known that if something is announced as an April Fool's joke, it's likely to be implemented a few years later. The only example that comes to mind is the 16-bit instruction set for the ARM processor, announced as 'Thumb'; but I know there have been others.
You may be right about the STL being complex, but the standard string class doesn't in fact come from the STL - it was added because of the need for a standard string to unify all the incompatible QString, CString, MyString etc etc etc that were common in the mid-90s.
Personally I think that the problem with the STL is that it is far too simple (in some ways) and this makes it complex to use. For example, std::map lacks any way to iterate over the keys of the map. Instead you can get an iterator over key, value pairs. From the viewpoint of designing a minimal interface this makes sense - a separate keys_begin(), keys_end() sequence would be redundant when you can already iterate over everything. But it would be a handy shortcut.
AFAIK the standard library specification doesn't make any guarantees about thread safety (a big deficiency, I agree), so your question is really one about implementations. As far as I know most newer std::string implementations do not use reference counting because it's difficult to make it thread-safe.
I'd agree that if you have real performance or thread-safety requirements that block you from using std::string (even if you make some assumptions about the implementation), then you could be justified in rolling your own. But even then the sensible thing to do would be to make the interface as close to std::string as reasonably possible (perhaps omitting the direct character writing with operator[], since this makes copy-on-write difficult).
Well, to be honest, the QString class is substantially more powerful than the C++ string class. Most especially in casting to and from other data types.
boost::lexical_cast
Well, okay, I'm proposing a third party library to provide what Qt's string class has built-in. But in a way this illustrates an advantage of using the standard string (or other standard classes) rather than rolling your own. You are able to take advantage of lots of third-party code, including the excellent work at boost.org.
Moreover, it supports the full range of internationalised characters,
You can make a basic_string of whatever character type you wish, including wchar_t. I guess it's unfortunate that the standard 'string' is an alias for basic_string<char,...> instead of using 16-bit or 32-bit characters, but it's not a disadvantage of the string class itself.
it automatically casts as neede and passes by value as needed as well.
The standard C++ string has value semantics, so you can pass it by value (and usually do so efficiently). In this respect it's just like an int - you can pass and return strings by value, and two strings are equal iff they have the same characters.
I'm sure the Qt string class is great, the question is, is it so much more wonderful that it justifies being different from the rest of the world?
Now come on, you're as well aware as I am of the problems with the standard C char* strings. Making a new string class is certainly justified if all you have to work with is something as error-prone as null-terminated character pointers. (And you may argue that char*s are entirely safe to work with, and only stupid programmers make mistakes; but I am a stupid programmer and judging by bugtraq, so are most others. Even assuming perfect programmers who don't mind doing memory allocation manually, a C-style string cannot store data containing embedded zero bytes.)
Back in 1993 or whenever, it was entirely reasoable for Qt and other C++ libraries - heck, even C libraries - to define their own string classes. I don't think that applies now - it's unlikely that Qt's string has any strong enough advantage over the standard string to make it worth introducing Yet Another String Class.
Replacing a type with something demonstrably better is fine. Pointlessly reinventing the wheel is not.
Ah, but can you link a 32-bit program with your 64-bit system libraries? Want two of every library?
Well, yes. I expect that OSes for Opteron will include two versions of every library for a while to come. I mean, Windows still provides all the 16-bit API calls.
It wouldn't require every library - just enough libraries to run dodgy nonportable applications (such as the JDK) which are available only in 32-bit format. Such apps usually don't use many libraries beyond libc anyway
It depends what you want to run. If you just want to run binary-only applications that are currently for i386 then there's not much advantage. By the same argument, when the 386SX came out a user running the currently available DOS software would be better off sticking with the 286, since it was slightly faster at the same clock speed for 16-bit code. (Yes I know the 386DX came out first... but it was very expensive.)
Myself, I'd just buy a new Linux CD and get all my applications recompiled for Opteron. YMMV.
Note that the Opteron has fairly good performace for 32-bit code, perhaps better than the Pentium IV at the same price, so even if you never intend to go 64-bit it might not be a bad purchase.
Is it too much to ask that the next Qt will use the standard C++ string class instead of its own reinvention and kitchen-sink-itis that it suffers from at the moment?
For the relatively small number of programs (at least on Linux) that have trouble with 64-bit longs, just compile as i386 code. The Opteron is backwards compatible with 32-bit code and gets reasonable performance out of it.
Just once, it would be nice to have a link to a motherboard review that wasn't split over 15 different sections.
'Without dragging on anymore, let's see what VIA's K8T800 chipset is capable of' - well, without dragging on any more than going to the next page after about two paragraphs...
Somebody should simply have programmed the computer with ISO 3103, Method for preparation of a liquor of tea for use in sensory tests; or with BS 6008, How to make a standard cup of tea. See the Jargon File.
Slashdot Mirror
A language holy war isn't justified, but neither should we ignore the simple fact that almost all buffer overflows happen in C or other relatively low-level languages, and almost none in higher-level languages. Yes, you can program safely in C, and you can program unsafely in Ada if you choose to. (In C++ you can do both with equal ease.) But there's something to be said for a language that makes it simple to do the right thing, and requires a bit more explicitness and verbosity to do the wrong thing. With C it is often the opposite.
Actually, I wouldn't blame C so much as the standard library. If there were a decent set of variable-sized array classes, safe string classes and so on included as part of the standard C library, we probably wouldn't see so many problems.
Microsoft's security holes are another issue altogether and often related to 'active content' and other moronic ideas. Language wars certainly aren't relevant there.
Well in programming there isn't really an equivalent of particular components being below spec; either a program has a bug or it doesn't, and every copy of that program has the same behaviour. It's not as if one in every 1000 compilations of GNU Hello come out defective.
What you can do is defensive programming, so that even if some other code is buggy your program tries to stagger on rather than crash. But this is really difficult - where do you draw the line? If a function is specified as adding two numbers, should the caller also check that the numbers have been added correctly? If so you are just rewriting the code yourself. At best you can put in checks for a few obvious things like returning null when the specification says not-null, but in many programming languages (C++ with references, C with splint, Nice) this can be enforced by the compiler so a run-time check isn't needed.
Not quite the same: a fixed-length buffer is where you _know_ there is a bug - you know the program will crash or do weird things when given a too-long input. Not having buffer overflows is not part of any advanced fault-tolerant strategy; it's just the basic discipline of not releasing code you know is buggy.
Much more interesting is how to code for robustness in the face of bugs you _don't_ know about. That is very tricky, although encapsulating access to data structures so they're always in a sane state can help, also adding sanity checking, checked invariants and assertions (if you feel it safer to abort the program than continue).
There will always be bugs. The question is how much time you're prepared to spend per bug eliminated. This is an engineering tradeoff.
In the short term the ISPs need to keep spam off their network. In the longer term, once nobody seems spam any more (because their ISP or mail client has filtered it out, based on trusted senders or micropayments or hash cash or whatever), spammers will no longer make money and will stop spamming.
Actually, I'd reckon that ISPs will move to a model where large users pay by the bit (many already do), so spam is not really their problem: it's the spamming ISP that foots the bill.
I'm an MEng and I've still written programs that crash... so have you. It's not a question of certification but just how much time you're prepared to take writing some code (by which I include choice of method, programming language and so on) and testing it. You can have thirty years of experience and still bang out flaky code if you're in a hurry. And if flaky code is all that's needed for the particular task, why not?
Rather than regulation we should let the market decide. Vendors could undertake: I will pay you $100 for each crash. Sometimes this already happens, eg with guarantees about the number of nines in server systems. The biggest problem is deciding responsibility for any faults. If an operating system call, which (according to POSIX or whatever) should not return null, one day does return null and the application crashes, who should pay up? And how do you find out whose fault it was? Running the whole system in some kind of virtual machine where you can roll back the last few seconds of execution would be one answer.
I'd hardly call it end-to-end. Here we have the mail server poking its nose into what type of mail is being delivered. It would make more sense for the mail system to get out of the way, deliver the messages, and let the users decide what they want to receive. Nobody advocates that IP routers should inspect each packet to see if it contains spam.
However, authenticated connection for mail delivery might not be a bad idea anyway, to stop DoS attacks based on sending millions of messages - even if all those are rejected by the recipient it still clogs the network, and unlike spammers, DoSers aren't trying to make money but just to cause a nuisance.
Apparently the main point of AMTP is to make it harder to spoof addresses. But it's still possible, so I don't think AMTP will change the general rule that no message header is to be trusted. PGP signatures blah blah blah are the only way to make sure a message comes from who it claims to.
Despite having Internet access at the time, I never heard of the Dancing Baby until it was mentioned on Ally McBeal (which I do not watch) or included on some crappy cover CD.
As far as I can tell it was a Windows executable which people sent to each other, and which when run displayed an animation of... a dancing baby.
Now unquestioningly running executables that people send you is not a good practice. But the Dancing Baby would encourage people to get into this bad habit because otherwise... well, you don't get to see the baby.
So it could be argued that the DB messages are indirectly responsible for Sobig and other worms.
The article says that the competition is to implement the System.Windows.Forms libraries. But I thought Miguel was doing some work to use Wine to implement this, since System.Windows.Forms (in true Microsoft style) is just a thin wrapper around the Win32 API.
.net stuff was meant to be portable and compatible and stuff?
Oh wait, that's Mono, not dotgnu. But why can't dotgnu do the same thing?
Or the other work that Mono is doing, a pure C# implementation of System.Windows.Forms using GTK#, why can't dotgnu use that? I thought this
I don't understand why on Slashdot, the main application of any display improvement is automatically assumed to be the latest skin for GTK or kewl Enlightenment theme. Eye candy is about the least important thing in a desktop.
Stollen patents? That would explain a lot of the bloat, I guess...
If what you say is true, and SCO (Calderuman) itself would not get most of the money, then either investors are too stupid to realize this, or the current stock price represents a market view that SCO are quite likely to win.
I believe the post you refer to is an attempt to test the metamoderation system by posting knowledgeable-sounding nonsense. For example, a hardware decoder cannot 'fractalize regions' - that would be something to do in the *encoder* and it would require support in the file format.
Myself I metamoderated as neither Fair nor Unfair, though if I had spotted the 'are you watching this?' signature before hitting submit I might have taken a closer look.
One reason to buy SCO stock is to hedge against them winning.
Suppose SCO is demanding $100 per Linux server, and you have 10 such servers. Then if they win you will need to find $1000. If SCO's stock price currently reflects a 5% chance of them winning, then any stock you do buy will increase 19-fold in value if they win. Therefore you need to buy $1000/19 worth of SCO stock to hedge against the risk. Of course you'd do this only if you think the 5% estimation by the market is about right, or too low - or if you think it's a bit too high but you're risk-averse.
If SCO wins, your stock should appreciate in value enough to cover the protection money you have to pay. If SCO lose, you've wasted about $52 on their now-worthless stock.
It's well known that if something is announced as an April Fool's joke, it's likely to be implemented a few years later. The only example that comes to mind is the 16-bit instruction set for the ARM processor, announced as 'Thumb'; but I know there have been others.
You may be right about the STL being complex, but the standard string class doesn't in fact come from the STL - it was added because of the need for a standard string to unify all the incompatible QString, CString, MyString etc etc etc that were common in the mid-90s.
Personally I think that the problem with the STL is that it is far too simple (in some ways) and this makes it complex to use. For example, std::map lacks any way to iterate over the keys of the map. Instead you can get an iterator over key, value pairs. From the viewpoint of designing a minimal interface this makes sense - a separate keys_begin(), keys_end() sequence would be redundant when you can already iterate over everything. But it would be a handy shortcut.
AFAIK the standard library specification doesn't make any guarantees about thread safety (a big deficiency, I agree), so your question is really one about implementations. As far as I know most newer std::string implementations do not use reference counting because it's difficult to make it thread-safe.
I'd agree that if you have real performance or thread-safety requirements that block you from using std::string (even if you make some assumptions about the implementation), then you could be justified in rolling your own. But even then the sensible thing to do would be to make the interface as close to std::string as reasonably possible (perhaps omitting the direct character writing with operator[], since this makes copy-on-write difficult).
boost::lexical_cast
Well, okay, I'm proposing a third party library to provide what Qt's string class has built-in. But in a way this illustrates an advantage of using the standard string (or other standard classes) rather than rolling your own. You are able to take advantage of lots of third-party code, including the excellent work at boost.org.
You can make a basic_string of whatever character type you wish, including wchar_t. I guess it's unfortunate that the standard 'string' is an alias for basic_string<char, ...> instead of using 16-bit or 32-bit characters, but it's not a disadvantage of the string class itself.
The standard C++ string has value semantics, so you can pass it by value (and usually do so efficiently). In this respect it's just like an int - you can pass and return strings by value, and two strings are equal iff they have the same characters.
I'm sure the Qt string class is great, the question is, is it so much more wonderful that it justifies being different from the rest of the world?
Now come on, you're as well aware as I am of the problems with the standard C char* strings. Making a new string class is certainly justified if all you have to work with is something as error-prone as null-terminated character pointers. (And you may argue that char*s are entirely safe to work with, and only stupid programmers make mistakes; but I am a stupid programmer and judging by bugtraq, so are most others. Even assuming perfect programmers who don't mind doing memory allocation manually, a C-style string cannot store data containing embedded zero bytes.)
Back in 1993 or whenever, it was entirely reasoable for Qt and other C++ libraries - heck, even C libraries - to define their own string classes. I don't think that applies now - it's unlikely that Qt's string has any strong enough advantage over the standard string to make it worth introducing Yet Another String Class.
Replacing a type with something demonstrably better is fine. Pointlessly reinventing the wheel is not.
Well, yes. I expect that OSes for Opteron will include two versions of every library for a while to come. I mean, Windows still provides all the 16-bit API calls.
It wouldn't require every library - just enough libraries to run dodgy nonportable applications (such as the JDK) which are available only in 32-bit format. Such apps usually don't use many libraries beyond libc anyway
It depends what you want to run. If you just want to run binary-only applications that are currently for i386 then there's not much advantage. By the same argument, when the 386SX came out a user running the currently available DOS software would be better off sticking with the 286, since it was slightly faster at the same clock speed for 16-bit code. (Yes I know the 386DX came out first... but it was very expensive.)
Myself, I'd just buy a new Linux CD and get all my applications recompiled for Opteron. YMMV.
Note that the Opteron has fairly good performace for 32-bit code, perhaps better than the Pentium IV at the same price, so even if you never intend to go 64-bit it might not be a bad purchase.
Is it too much to ask that the next Qt will use the standard C++ string class instead of its own reinvention and kitchen-sink-itis that it suffers from at the moment?
For the relatively small number of programs (at least on Linux) that have trouble with 64-bit longs, just compile as i386 code. The Opteron is backwards compatible with 32-bit code and gets reasonable performance out of it.
Just once, it would be nice to have a link to a motherboard review that wasn't split over 15 different sections.
'Without dragging on anymore, let's see what VIA's K8T800 chipset is capable of' - well, without dragging on any more than going to the next page after about two paragraphs...
Somebody should simply have programmed the computer with ISO 3103, Method for preparation of a liquor of tea for use in sensory tests; or with BS 6008, How to make a standard cup of tea. See the Jargon File.