Note: I did a search for this and didn't come up with any threads. If it has been discussed before... my apologies.


Recently I introduced D to a friend of mine (a C.S. grad student at Purdue). His reaction was the usual "wow, awesome". Then he became concerned about pointer safety. D allows unrestricted access to pointers.

I will skip the "pointers are unsafe" rigmarole.

Should D provide something analogous to the C# unsafe keyword?

On 2006-02-12 14:11:05 -0800, nick <nick.atamas@gmail.com> said:

> Note: I did a search for this and didn't come up with any threads. If it
> has been discussed before... my apologies.
> 
> 
> Recently I introduced D to a friend of mine (a C.S. grad student at
> Purdue). His reaction was the usual "wow, awesome". Then he became
> concerned about pointer safety. D allows unrestricted access to pointers.
> 
> I will skip the "pointers are unsafe" rigmarole.
> 
> Should D provide something analogous to the C# unsafe keyword?

Don't play with the pointers if you want them to point to the right place.  It's not like people are injecting malicious sourcecode into your projects.

-S.

S. Chancellor wrote:
> On 2006-02-12 14:11:05 -0800, nick <nick.atamas@gmail.com> said:
> 
>> Note: I did a search for this and didn't come up with any threads. If it has been discussed before... my apologies.
>>
>>
>> Recently I introduced D to a friend of mine (a C.S. grad student at Purdue). His reaction was the usual "wow, awesome". Then he became concerned about pointer safety. D allows unrestricted access to pointers.
>>
>> I will skip the "pointers are unsafe" rigmarole.
>>
>> Should D provide something analogous to the C# unsafe keyword?
> 
> Don't play with the pointers if you want them to point to the right place.  It's not like people are injecting malicious sourcecode into your projects.
> 
> -S.
> 

I guess skipping the rigmarole was a bad idea.
I work with many EE people. EE people don't know how to write code. They
are often very intelligent, but simple lack the experience and proper
coding practices.

Bjarne said that most programmers are amateurs. There is no helping that. A good language will provide safeguards against errors for amateurs. This would be one of them.

When I get a piece of code from an colleague, I want to be sure that he didn't use pointers to mess something up. Having an unsafe keyword prevents his code from being compiled unless I provide the --allow-unsafe flag. That's a big assurance for me that his code doesn't mess up my heap.

"nick" <nick.atamas@gmail.com> wrote in message news:dsoifi$2von$1@digitaldaemon.com...
> I guess skipping the rigmarole was a bad idea.
> I work with many EE people. EE people don't know how to write code. They
> are often very intelligent, but simple lack the experience and proper
> coding practices.
>
> Bjarne said that most programmers are amateurs. There is no helping that. A good language will provide safeguards against errors for amateurs. This would be one of them.

The thing is, pointer use in D is pretty much restricted to interfacing with C libs.  Using D normally, you should almost never have to touch pointers; the one real exception to this is the result of 'in' expressions.

> When I get a piece of code from an colleague, I want to be sure that he didn't use pointers to mess something up. Having an unsafe keyword prevents his code from being compiled unless I provide the --allow-unsafe flag. That's a big assurance for me that his code doesn't mess up my heap.

No code can mess up the heap, unless you're running with protected mode off. Which can't really happen with any OSes made in the last 15 years or so.

Jarrett Billingsley wrote:
> "nick" <nick.atamas@gmail.com> wrote in message
> news:dsoifi$2von$1@digitaldaemon.com...
> The thing is, pointer use in D is pretty much restricted to interfacing with
> C libs.  Using D normally, you should almost never have to touch pointers;
> the one real exception to this is the result of 'in' expressions.
> 
> No code can mess up the heap, unless you're running with protected mode off. Which can't really happen with any OSes made in the last 15 years or so.

I realize that pointers aren't meant to be used for things other than interfacing with C. However, it seems to me that D currently doesn't enforce this. A C programmer might be tempted to muck about with pointers. For example.

-------------------------------------
CODE:
import std.stdio;
class A
{
	private int data[];

	public this()
	{
		data.length = 10;
	}

	public void printSelf()
	{
		writefln("Data: ", this.data);
	}
}

void surprise(inout A a)
{
	byte *ap = cast(byte *)(a);
	ap[9] = 5;
}

int main()
{
	A a = new A();
	a.printSelf();
	surprise(a);
	a.printSelf();
	return 0;
}
-------------------------------------
OUTPUT:
Data: [0,0,0,0,0,0,0,0,0,0]
Data: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,2768,1245184,1,0,0,0
<..SNIP..>
,0,0,0,0,0,0,0,0,0,0,0]


When I compile someone else's code I want an absolute guarantee that they aren't doing anything unsafe with their pointers. If they are doing something unsafe, I'd like to know.

Better yet, I'd like to know if someone's library is unsafe when I link against it.

What's worse, I can use the function prototype:

void surprise(inout A a);

and the results will be exactly the same. That just seriously breaks all the high level language features that D puts in place. So I guess my question is: "Shouldn't there be a mechanism to deal with this?"

nick wrote:
> What's worse, I can use the function prototype:
> 
> void surprise(inout A a);
> 
> and the results will be exactly the same. That just seriously breaks all the high level language features that D puts in place. So I guess my question is: "Shouldn't there be a mechanism to deal with this?"
Sorry, that's meant to be: void surprise(in A a). As in should not be changed inside the function call.

It's been a long day.

nick wrote:
> Jarrett Billingsley wrote:
>> "nick" <nick.atamas@gmail.com> wrote in message news:dsoifi$2von$1@digitaldaemon.com...
>> The thing is, pointer use in D is pretty much restricted to interfacing with C libs.  Using D normally, you should almost never have to touch pointers; the one real exception to this is the result of 'in' expressions.
>>
>> No code can mess up the heap, unless you're running with protected mode off. Which can't really happen with any OSes made in the last 15 years or so. 
> 
> I realize that pointers aren't meant to be used for things other than
> interfacing with C.

What about someone who simply wants to maintain multiple references to a non-class type?  C interfacing might be the most common use, but it certainly isn't the only use.


Sean

> What about someone who simply wants to maintain multiple references to a non-class type?  C interfacing might be the most common use, but it certainly isn't the only use.
> 
> 
> Sean

References to non-class types are fine, but they should be maintained using typesafe pointers, which D provides.

"Pointers are provided for interfacing with C and for specialized systems work....Most conventional uses for pointers can be replaced with dynamic arrays, out and inout parameters, and reference types."

http://www.digitalmars.com/d/arrays.html

You asking this is just further proof that there are people who will try to use unsafe pointers and that we need the unsafe keyword a. la. C#.

I am in no way trying to attack you. I am just pointing out that C and C++ breeds bad programming practice, and we need protection from them.

> I am in no way trying to attack you. I am just pointing out that C and C++ breeds bad programming practice, and we need protection from them.

Are you serious?

Similarly, I am not trying to attack you, but this is terribly jejune. C and C++ and pointers are no more or less hazardous than is a hammer or a syringe or a stick of dynamite. If you're bashing in a nail or injecting a patient or excavating a tunnel these are the best tools to have. They do not "breed" bad practice. That comes from process, experience and attitude.

I'll repeat something I observed here a long time ago: the very worst coding I've come across, by a country mile, was a group of Java "consultants" (from one of the Big 5, or is it now Big 4, accountancy firms). I've seen bad C, bad COM, bad .NET, and, of course, plenty of bad C++, but nothing compares to the masses of swill that these jokers spewed forth. And nary a pointer in sight. Myself and several other (non-Java) consultants were brought in to fix the mess, and it took many days and hundreds of applications of source cleaning tools (which, thankfully, were written in a fast language) to start to clear up the junk.

Further, I'd suggest that an understanding of what goes on beneath the covers is actually a hazardous skill to be lacking. (You might find http://joelonsoftware.com/articles/ThePerilsofJavaSchools.html illustrative of my point.)

Walter correctly sought to incorporate pointers in D as first class parts of the language. In the same way that I avoid IOStreams in C++, one tends to avoid pointers in D.

Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.