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?

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.