Yes you _can_ still reference uninitialized pointers and double-free memory in C++, but only if you write low-level pointer-manipulating code to start with. Most modern C++ code will use objects created on the stack, references, and smart pointer classes like std::auto_ptr or boost::shared_ptr.
The advice you give about C and C++: 'They're powerful because they're dangerous, and you should only use them when the situation demands it', applies equally to pointers in C++. The fact that you _can_ write unsafe code in a programming language is not a reason to avoid it. A bad language or library is one that forces you to resort to low-level operations to get any work done, or makes it seductively easy to do unsafe things and difficult to do the safer equivalents.
What other programming language in widespread usage lacks a built-in, pointer safe string class?
Well, C++ lacks one, it is provided by the standard library. I'm pretty sure that most functional languages like ML and Haskell do not have a built-in string type but instead get it from the standard library. And arguably even Java's String is not built in (not that I'd suggest trying to use an alternative string class). Like I said, it is not the language itself but the library it is provided with. There's no need for a type like 'string' to be built into the language itself, it can be, but a decent library can also provide safe ways of doing string handling.
You're right, C or C++ code with explicit memory allocation still makes it too easy to code double-free bugs. But despite the recent zlib vulnerability, double-free is not the most common cause of security holes.
It would help if the standard free() did a bit more checking, in particular making sure you can only free() an address you've previously malloc()ed. That would make it slower, but not too much slower. Programmers could always turn off this checking for code that relies on allocating and freeing lots of blocks quickly. But I feel that having things safe by default, with the possibility to turn on 'fast but more dangerous mode', is a better design than providing the unsafe facilities by default.
If you program in C++ with the STL, you hardly ever need to do pointer arithmetic, indeed the use of pointers themselves is relatively rare. In C it may still be unavoidable.
I agree with you about the integer overflow bugs; it would have been much better if C and C++ could give an error for these rather than silently continuing. Stroustrup claims that arithmetic operations in C++ don't throw exceptions because overflow detection happens asynchronously on many systems. But that seems like a pretty weak excuse; you could at least have some barrier in the code which checks for overflow that recently happened.
And yes, C++ does have exceptions, and it's better to use a library which throws exceptions on failure than to call system calls directly.
I think we'd all be better off if everyone switched to SML, but I wanted to say you _can_ avoid the most common bug-patterns in C and almost all of them in C++.
The article talks about three big classes of vulnerabilities: format string bugs, buffer overruns, and input validation bugs. The first two need not ever occur in a C++ program: the STL containers do not use fixed-size buffers, and the STL input/output routines don't use format strings, printf() or scanf(). If you deliberately ignore what the C++ standard library provides for you and go back to C library routines and fixed-size arrays you become more vulnerable to these attacks. (Out-of-bounds subscripts can still happen with the STL, unless you are using an implementation which does bounds checking on vector subscripts and the like. IMHO this should be the default, manually turned off for speed-critical code.)
Even in C there is a good choice of libraries for string manipulation and containers which don't allow buffer overruns.
It's not C and C++ which are at fault, it's the C *standard library*.
The thing is, you can program in a low-level language yet still avoid bugs like buffer overflows and failing to handle NUL characters in strings.
In C, it just requires using a library like glib for your string handling, and some similar library to provide bounds-checked arrays.
In C++, it means avoiding char * strings like the plague and using the standard 'string' class instead; similarly using 'vector' or other STL containers instead of C-style arrays.
I think it would help if there were a standard, minimal C string library, and if existing APIs including system calls were given equivalents using these. So open() could take a pointer to a 'const struct String' rather than a char *. Having done this, the existing functions like strlen() and strdup() could be declared deprecated. There are plenty of decent string manipulation libraries for C, what's lacking is a single one library which everyone can agree to support.
At least in C++ there is a standard 'string' type, although some people insist on reinventing the wheel (Microsoft's MFC with CString, Qt with QString).
What I mean is, squeezing more onto the thin pipe between ISP and user is where you see the biggest improvement, and it's also the easiest to arrange since it doesn't require the Whole World(tm) to move to a new protocol or install new software.
But al-Jazeera's behaviour after 9/11 didn't seem impartial. They were happy to broadcast taped recordings by bin Laden, seemingly at a time of his choosing. In most countries such recorded messages are called political broadcasts, they must be clearly labelled as such, and must be allocated to all sides equally. While other viewpoints were represented on the station, including interviews with Western leaders, it is not impartial to give free advertising to just one of the sides.
Isn't it intended to provoke Iraq into using chemical or biological weapons? That would show to the world that the US was right all along (assuming they are right) and also provide an excuse for countries such as France to get on side. Of course, the politicians will never admit that this is an aim , and if Iraq does use such weapons it's unlikely they would be so polite as to restrict it to a token attack.
The proxy server RabbIT already does compress images to JPEGs, among other things. All of the things this 'Propel' product does are already done by free software, it's just a case of having them neatly packaged together.
Caching unchanged bits of documents sounds rather like rproxy, an http proxy which uses the rsync protocol to just send changes to documents. But that project is inactive because apparently there isn't the demand for it.
Personally, I think that the right place for this kind of cleverness is just between the ISP and the user. So the ISP runs a proxy server which downloads things as normal, and then has a single connection (perhaps over a compressed ssh tunnel) with the user's PC, over which it can just send deltas against pages cached on the user's PC. So all of the effort is focused on the real bottleneck, the modem link.
I don't think ISPs need to buy this company's product, they could put together an equivalent using rsync and a few weeks' perl coding.
If (64-bit Windows) = true and (applications support)=true then (massive upgrade cycle)?
They're trying to sound geeky but failing. Everyone knows that 'x == true' is better stated as just 'x'. Couldn't they have just written it in English?
It's not blatant greed, it's blatant *stupidity*. People and companies will always be greedy. The point is to channel that greed so that it benefits society as a whole. Capitalism with competition is one attempt to achieve this. The patent system, also, should be designed so that when companies act in their own interest they are also benefiting the public - for example, the public gets a benefit in the long run from the invention being published rather than kept secret. But when the patent system is extended to software and particularly when the standards of patentability are so trivial, the behaviour it rewards can become detrimental to the economy as a whole, as the article suggests.
The answer is not to castigate individual companies for acting in the interest of their shareholders - even though their actions may be immoral, any one case of patent abuse will be a small part of the whole, and persuading one company to stop its actions for fear of bad PR does very little to stop other companies applying for bogus patents or to stop the patent office granting them. The answer is to fix the system.
By this logic, you should have access to every developer's code from the moment he or she writes it.
But of course. Why not? The developer is well-placed to give an opinion on whether code is stable enough for production use but he cannot know the circumstances of every single user. You might desperately need a particular bug fix, for example. Or more importantly, if you are working on the same project yourself or reusing some of the code, you'd want to keep up-to-date with the latest developments so you don't duplicate work.
For proprietary software there are reasons to keep development versions secret until an official release. You don't want competitors getting advance knowledge of what will be in the next version, you don't want users downloading new versions they have not paid for, and you'd rather arrange publicity through choreographed launches and press releases. Plus, you wouldn't want anyone to see that the promised new feature for next month is only half-implemented.
For free software development none of these reasons really apply (with the possible exception of commercial free software such as Linux distributions where you do have competitors, launches, marketing departments and all that). By all means make official 'releases', but more and more projects are seeing it makes sense to provide read-only access to the source code repository so that if people need code that isn't in the latest release, they can get it without waiting. There are few projects now following a pure 'cathedral' model.
It's pretty easy to kill performance if you go sticking shading and bitmaps on all your widgets.
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything, and that many users think this looks kewl, and that in any case Mac OS X and other systems seem to exploit the video card's hardware to do this stuff quickly, wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
Ah. In that case, an STL implementation that uses a single vector specialization wouldn't be portable. But still, surely most C++ systems in practice have all pointers the same size, otherwise this technique would not be mentioned so often (I think it even appears in Stroustrup's book).
I always thought that on a platform that couldn't address every single byte, you'd simply make sure that chars were word-aligned. After all, i386 hardware cannot address individual bits, but who heard of a C++ implementation where a bool * was larger than other pointer types?
Templates only seem to be a necessary evil in OO languages that don't ultimately inherit all objects from one object.
What, like Java? The most commonly used types in Java (int, bool, maybe float) don't inherit from Object.
You can manually put them into wrapper objects like Integer which do inherit from Object, but you could equally well do that in C++ by defining a single Pointer class which wraps a pointer-to-void. But of course in C++ you wouldn't want to, because you can have type-safe containers without such shenanigans.
You're right that templates can lead to object code bloat; if you used a templated container and specialized it for five different types, then five lumps of object code would be compiled.
On the other hand, each specialization could be fast and memory-efficient because the compiler knows the size of the objects being stored - none of this putting integers into and out of boxes at run time whenever you want to store them in a container, as happens in Java and in many implementations of more high-level languages.
Also, in the STL there is a single implementation of most containers specialized for pointers, so a vector and a vector share a single lump of object code. (As you'd expect, since all pointers are the same size no matter what the type of thing they point to.)
I think that on the whole the speed advantages of generating code specialized to a single type, with fewer branches and comparisons at run time, outweighs the cache thrashing effects of generating larger object code. If you disagree, you are free to only use containers of pointers and thus share a single implementation for all your containers, as would probably happen if you used an equivalent container library in C.
But at the end of the day, if you are worried about speed, benchmark. Otherwise, concentrate on writing code which is correct and whose meaning is clear to a human reader. Templates certainly help with both of those, at least for the experienced C++ programmer.
"unrefactored" code - code which has a lot of duplication and should be cleaned up
The other day I hacked up a similarity
tool which gives an index between 0 and 1 of the cross-redundancy between files. (It gzips the concatenation of the two files and compares this with gzipping them independently.) Maybe a version control system could run this on all new file checkins, so a file is rejected if it is too similar to some file already under version control. This would cut down on cut-and-paste of existing code, which is generally a Bad Thing (refactor instead).
They could link to Linux-mentioning articles *as well as* rather than *instead of* the Windows articles, but if it comes down to a choice of a story about one or the other I think a Linux article would make more interesting reading. And Slashdot does have limited space (there are far more story submissions than ever appear on the front page) so this situation is quite likely.
It's not so much OS fascism as the fact that an article saying 'click here, click there, download that' is rather dull. A Linux article has the additional spin of interviewing 'Roberto Campari, lead developer of the free Videotromatic package' or whatever, and explaining the technical developments in more depth. And it can explain how to write a shell script to partly automate the task of tweaking volume levels, or stuff like that. Unix just makes for better literature than Windows.
Slashdot Mirror
Yes you _can_ still reference uninitialized pointers and double-free memory in C++, but only if you write low-level pointer-manipulating code to start with. Most modern C++ code will use objects created on the stack, references, and smart pointer classes like std::auto_ptr or boost::shared_ptr.
The advice you give about C and C++: 'They're powerful because they're dangerous, and you should only use them when the situation demands it', applies equally to pointers in C++. The fact that you _can_ write unsafe code in a programming language is not a reason to avoid it. A bad language or library is one that forces you to resort to low-level operations to get any work done, or makes it seductively easy to do unsafe things and difficult to do the safer equivalents.
Well, C++ lacks one, it is provided by the standard library. I'm pretty sure that most functional languages like ML and Haskell do not have a built-in string type but instead get it from the standard library. And arguably even Java's String is not built in (not that I'd suggest trying to use an alternative string class). Like I said, it is not the language itself but the library it is provided with. There's no need for a type like 'string' to be built into the language itself, it can be, but a decent library can also provide safe ways of doing string handling.
You're right, C or C++ code with explicit memory allocation still makes it too easy to code double-free bugs. But despite the recent zlib vulnerability, double-free is not the most common cause of security holes.
It would help if the standard free() did a bit more checking, in particular making sure you can only free() an address you've previously malloc()ed. That would make it slower, but not too much slower. Programmers could always turn off this checking for code that relies on allocating and freeing lots of blocks quickly. But I feel that having things safe by default, with the possibility to turn on 'fast but more dangerous mode', is a better design than providing the unsafe facilities by default.
If you program in C++ with the STL, you hardly ever need to do pointer arithmetic, indeed the use of pointers themselves is relatively rare. In C it may still be unavoidable.
I agree with you about the integer overflow bugs; it would have been much better if C and C++ could give an error for these rather than silently continuing. Stroustrup claims that arithmetic operations in C++ don't throw exceptions because overflow detection happens asynchronously on many systems. But that seems like a pretty weak excuse; you could at least have some barrier in the code which checks for overflow that recently happened.
And yes, C++ does have exceptions, and it's better to use a library which throws exceptions on failure than to call system calls directly.
I think we'd all be better off if everyone switched to SML, but I wanted to say you _can_ avoid the most common bug-patterns in C and almost all of them in C++.
The article talks about three big classes of vulnerabilities: format string bugs, buffer overruns, and input validation bugs. The first two need not ever occur in a C++ program: the STL containers do not use fixed-size buffers, and the STL input/output routines don't use format strings, printf() or scanf(). If you deliberately ignore what the C++ standard library provides for you and go back to C library routines and fixed-size arrays you become more vulnerable to these attacks. (Out-of-bounds subscripts can still happen with the STL, unless you are using an implementation which does bounds checking on vector subscripts and the like. IMHO this should be the default, manually turned off for speed-critical code.)
Even in C there is a good choice of libraries for string manipulation and containers which don't allow buffer overruns.
It's not C and C++ which are at fault, it's the C *standard library*.
The thing is, you can program in a low-level language yet still avoid bugs like buffer overflows and failing to handle NUL characters in strings.
In C, it just requires using a library like glib for your string handling, and some similar library to provide bounds-checked arrays.
In C++, it means avoiding char * strings like the plague and using the standard 'string' class instead; similarly using 'vector' or other STL containers instead of C-style arrays.
I think it would help if there were a standard, minimal C string library, and if existing APIs including system calls were given equivalents using these. So open() could take a pointer to a 'const struct String' rather than a char *. Having done this, the existing functions like strlen() and strdup() could be declared deprecated. There are plenty of decent string manipulation libraries for C, what's lacking is a single one library which everyone can agree to support.
At least in C++ there is a standard 'string' type, although some people insist on reinventing the wheel (Microsoft's MFC with CString, Qt with QString).
What I mean is, squeezing more onto the thin pipe between ISP and user is where you see the biggest improvement, and it's also the easiest to arrange since it doesn't require the Whole World(tm) to move to a new protocol or install new software.
But al-Jazeera's behaviour after 9/11 didn't seem impartial. They were happy to broadcast taped recordings by bin Laden, seemingly at a time of his choosing. In most countries such recorded messages are called political broadcasts, they must be clearly labelled as such, and must be allocated to all sides equally. While other viewpoints were represented on the station, including interviews with Western leaders, it is not impartial to give free advertising to just one of the sides.
Isn't it intended to provoke Iraq into using chemical or biological weapons? That would show to the world that the US was right all along (assuming they are right) and also provide an excuse for countries such as France to get on side. Of course, the politicians will never admit that this is an aim , and if Iraq does use such weapons it's unlikely they would be so polite as to restrict it to a token attack.
The proxy server RabbIT
already does compress images to JPEGs, among other things. All of the things this 'Propel' product does are already done by free software, it's just a case of having them neatly packaged together.
Caching unchanged bits of documents sounds rather like rproxy, an http proxy which uses the rsync protocol to just send changes to documents. But that project is inactive because apparently there isn't the demand for it.
Personally, I think that the right place for this kind of cleverness is just between the ISP and the user. So the ISP runs a proxy server which downloads things as normal, and then has a single connection (perhaps over a compressed ssh tunnel) with the user's PC, over which it can just send deltas against pages cached on the user's PC. So all of the effort is focused on the real bottleneck, the modem link.
I don't think ISPs need to buy this company's product, they could put together an equivalent using rsync and a few weeks' perl coding.
But factually, she is entirely correct. Someone needs to point out these things.
They're trying to sound geeky but failing. Everyone knows that 'x == true' is better stated as just 'x'. Couldn't they have just written it in English?
It's not blatant greed, it's blatant *stupidity*. People and companies will always be greedy. The point is to channel that greed so that it benefits society as a whole. Capitalism with competition is one attempt to achieve this. The patent system, also, should be designed so that when companies act in their own interest they are also benefiting the public - for example, the public gets a benefit in the long run from the invention being published rather than kept secret. But when the patent system is extended to software and particularly when the standards of patentability are so trivial, the behaviour it rewards can become detrimental to the economy as a whole, as the article suggests.
The answer is not to castigate individual companies for acting in the interest of their shareholders - even though their actions may be immoral, any one case of patent abuse will be a small part of the whole, and persuading one company to stop its actions for fear of bad PR does very little to stop other companies applying for bogus patents or to stop the patent office granting them. The answer is to fix the system.
But of course. Why not? The developer is well-placed to give an opinion on whether code is stable enough for production use but he cannot know the circumstances of every single user. You might desperately need a particular bug fix, for example. Or more importantly, if you are working on the same project yourself or reusing some of the code, you'd want to keep up-to-date with the latest developments so you don't duplicate work.
For proprietary software there are reasons to keep development versions secret until an official release. You don't want competitors getting advance knowledge of what will be in the next version, you don't want users downloading new versions they have not paid for, and you'd rather arrange publicity through choreographed launches and press releases. Plus, you wouldn't want anyone to see that the promised new feature for next month is only half-implemented.
For free software development none of these reasons really apply (with the possible exception of commercial free software such as Linux distributions where you do have competitors, launches, marketing departments and all that). By all means make official 'releases', but more and more projects are seeing it makes sense to provide read-only access to the source code repository so that if people need code that isn't in the latest release, they can get it without waiting. There are few projects now following a pure 'cathedral' model.
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything, and that many users think this looks kewl, and that in any case Mac OS X and other systems seem to exploit the video card's hardware to do this stuff quickly, wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
French for D-Day is le jour 'J'. So I think it is just picking the first letter.
OTOH I also heard that it stands for 'The day', with a long vowel as in thee.
As for the alternative dates: B-day was called off because the name would confuse the French.
Ah. In that case, an STL implementation that uses a single vector specialization wouldn't be portable. But still, surely most C++ systems in practice have all pointers the same size, otherwise this technique would not be mentioned so often (I think it even appears in Stroustrup's book).
I always thought that on a platform that couldn't address every single byte, you'd simply make sure that chars were word-aligned. After all, i386 hardware cannot address individual bits, but who heard of a C++ implementation where a bool * was larger than other pointer types?
What, like Java? The most commonly used types in Java (int, bool, maybe float) don't inherit from Object.
You can manually put them into wrapper objects like Integer which do inherit from Object, but you could equally well do that in C++ by defining a single Pointer class which wraps a pointer-to-void. But of course in C++ you wouldn't want to, because you can have type-safe containers without such shenanigans.
I meant to say, a vector and a vector share the same code. But Slashdot did its usual stupid HTMLization on my comment.
You're right that templates can lead to object code bloat; if you used a templated container and specialized it for five different types, then five lumps of object code would be compiled.
On the other hand, each specialization could be fast and memory-efficient because the compiler knows the size of the objects being stored - none of this putting integers into and out of boxes at run time whenever you want to store them in a container, as happens in Java and in many implementations of more high-level languages.
Also, in the STL there is a single implementation of most containers specialized for pointers, so a vector and a vector share a single lump of object code. (As you'd expect, since all pointers are the same size no matter what the type of thing they point to.)
I think that on the whole the speed advantages of generating code specialized to a single type, with fewer branches and comparisons at run time, outweighs the cache thrashing effects of generating larger object code. If you disagree, you are free to only use containers of pointers and thus share a single implementation for all your containers, as would probably happen if you used an equivalent container library in C.
But at the end of the day, if you are worried about speed, benchmark. Otherwise, concentrate on writing code which is correct and whose meaning is clear to a human reader. Templates certainly help with both of those, at least for the experienced C++ programmer.
That picture on their web site makes the mat soft and comfortable. Rather than charging boring mobile phones, why not use it as a pillow?
There was once a movie 'Electric Dreams' which I've never seen but probably had nothing to do with this.
How is there a body to regulate Spanish? If it is based in Spain, do its pronouncements carry any force in Mexico, Cuba and the United States?
The other day I hacked up a similarity tool which gives an index between 0 and 1 of the cross-redundancy between files. (It gzips the concatenation of the two files and compares this with gzipping them independently.) Maybe a version control system could run this on all new file checkins, so a file is rejected if it is too similar to some file already under version control. This would cut down on cut-and-paste of existing code, which is generally a Bad Thing (refactor instead).
They could link to Linux-mentioning articles *as well as* rather than *instead of* the Windows articles, but if it comes down to a choice of a story about one or the other I think a Linux article would make more interesting reading. And Slashdot does have limited space (there are far more story submissions than ever appear on the front page) so this situation is quite likely.
It's not so much OS fascism as the fact that an article saying 'click here, click there, download that' is rather dull. A Linux article has the additional spin of interviewing 'Roberto Campari, lead developer of the free Videotromatic package' or whatever, and explaining the technical developments in more depth. And it can explain how to write a shell script to partly automate the task of tweaking volume levels, or stuff like that. Unix just makes for better literature than Windows.
Boring boring boring. HP will partner with Red Hat to offer Linux on Intel hardware. As if there weren't enough Linux-on-Intel server vendors already.
When is HP going to port Linux to its 128-processor Superdome PA-RISC boxes? That would make a worthwhile story on Slashdot.
Or failing that, even managing to sell laptops with Linux preinstalled and without the Microsoft tax.