Bill Joy's Takes on C#

f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"

Comments

What we should really call it...

[mcrbids]

C-Flat?

An Unsafe code example:

[CTalkobt]

Let's see... I wonder if this would be allowed if unsafe is now a keyword in C#:

a = (unsafe_case)( get_secure_password( "XX

The joys of MS programming languages.

Btw the open and close blockquote cause auto-indentation unless you force a [p] (substitute) on the line being blockquoted.

You don't say...

[RailGunner]

Writing safe and unsafe code is entirely the responsibility of the developer. A quote from the article: "Often a computer virus propagates by exploiting a simple programming error, typically a C program failing to check for buffer overflow, allowing input data to overwrite arbitrary portions of memory. Last year's Code Red worm exploited exactly such a bug in Microsoft IIS. "

Well no shit.

And this brings me to my point: Security is the job of the developer, not the language. The language can make it easier on the developer, but it really shouldn't be the end all / be all of secure code. For example, one way you can prevent buffer over-runs in C/C++ is by using strncpy() instead of strcpy().. As far as adding security to an insecure system as Joy writes, I have to wonder: Has Bill Joy ever written any kind of serious application? Does he know the first thing about programming? Is he *truly* advocating using "safe" languages for everything when secure programs can be written in other languages? Or is he truly willing to ban all "unsafe" languages like C, C++, Assembler, hell, it's still technically possibly to write machine code. Maybe he isn't going far enough - maybe all processors should be capable of only running Java BYTECODE natively. And yes, I am illustrating absurdity by being absurd. Joy needs to buy a clue here. I'll say it again - as developers writing secure applications is *OUR* job, not the job of the language we choose to develop in.

Re:define "unsafe" again please

[JDizzy]

That statement is a dangerous one for you reputation as a good admin.

Really, how so... is my reputation damaged for asking silly questions? I don't do c/c++, or java.. the most I do is perl, and php... so my reputation for the job I do is in good form in that regards.

Clearly, the lack of pointers to me would indicate an advantage in the fact that managing the pointer would be anoying for a developer. Why not let the compiler take the burden?

Two Kettles Arguing over whos Blacker

[MagikSlinger]

Alas, I doubt anyone will be reading this, but I'll say it anyway:

Java's security model always felt tacked on to me, but even still, it's pretty decent for the kinds of security issues it was meant to deal with. The problem is that Java can still be used to create viruses and other nasty problems, especially if it can sweet talk to user into giving the Java code more permissions than it would otherwise have. The same thing is true of ActiveX: all the security in the world won't protect you from a user who cranks the security in his IE down a few notches. The reason users would do this is to get access to a control or java app that can do something interesting or useful. For example, a virus scan of your harddrive.

This leads me to a basic observation: the usefulness and capabilities of a language or programming environment is directly proportional to the amount of damage it can inflict on a system. Both languages and environments have their benefits and drawbacks, but deciding based on security is pointless: security is fundamentally a user-developer level issue. No amount of language-level or environment-level features can make computing secure if the user and developer aren't willing to think securely as well. If you do add more secure language and environment security measures, then the usefuleness of your language/environment decreases (e.g., to protect your local hard-drived files from unwanted operations, you lose the ability to save/read anywhere on your harddrive from your application). You cannot have a useful programming language/environment and still make guaranteed secure programs.

C#'s unsafe section problems are not security problems, but robustness problems. The unsafe sections make it very easy to create code as crashable and bug ridden as a pure C/C++ app! Java's constraints don't make it more secure than C#, but they do make it easier to write robust code.

Even with the unsafe sections, you can still write really high quality C# code because no language/environment feature can ever replace the programmer's diligence in writing secure code. And if you want code that's less bug-ridden and more robust, avoid unsafe code sections like the plague.

My greatest qualm with C#'s unsafe section is knowing that a bunch of programmers raised on MS's crappy coding style will create components and other applications with great reams of unsafe code forcing everyone using .NET to drop their security precautions in order to get basic applications running thus creating the backdoor every script kiddie is waiting for.

Blame Unsafe Code on Developer, Not Language

[reallocate]

Writing safe code is the developer's responsibility. The language has nothing to do with it. If you wanna write in C and also check for buffer overflows, you're gonna have to do it yourself. Otherwise, pick a new language.