> An important part of the solution to buffer overflows is for folks to > ditch the C and C++ program languages.
C isn't at fault except in the sense that the car is at fault when someone drives into a wall. At most, the string libraries are at fault, and, even there, it's more a question of misusing them than of their being the problem. A good case could be made that they're part of the problem in that they make it easy to be sloppy in ways that create buffer overrun bugs, but all it takes to fix that is to refuse to use the non-size-checked calls. > Too bad the designers of the C language never thought about building > a safe string data type into the language in the first place. It would have been - would be - inappropriate, given what C was intended to be. If you want a language with high-level types like that, C is not what you're after, any more than (say) assembly is; this is not C's fault any more than it's assembly's fault. > A safe string data type could have also been added natively to the > language 20 years ago when the problem of string buffer overflows was > recognized. Not really. Try it sometime. It is probably possible to hammer it in somehow, but it would be a very poor fit to the rest of the language. C simply isn't designed to be a hand-holding kind of language. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Fun and Misc security discussion for OT posts. https://linuxbox.org/cgi-bin/mailman/listinfo/funsec Note: funsec is a public and open mailing list.
