Community

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.