I was hoping you guys would write the report for me... there may be some money involved.

I'm just kidding.

Actually, what I want is to know from the experience of people writing D how you liked/disliked it.
Also I need to post questions since the only documentation is on the Mars D site and Wiki D so I'm
kind of limited in articles and resources. There is a wealth of information on both sites but I may
need some information not on the sites. Citation is going to be a bitch indeed.

The way I'm going to write the report is on the "unique" features that D has:

Design by Contract
Template Syntax
Built-in Garbage Collector
Others...

Perhaps also go into advantages/disavantages over .NET (there are some articles already on newsgroup
that may help me).

Another topic that I have to do since it is a security class, is well, security. How can you secure
D from hackers, reverse engineering (if it is possible), and how D can be used to create viruses. I
could just half ass this topic depending on how much space I need to fill, since most are applied to
most languages anyway.

Thanks,
Jacob Santos

In article <cibpov$2ejf$1@digitaldaemon.com>, Gold Dragon says...

>How can you secure
>D from hackers,

Please could you be more specific in your question. It's a little too vague to be meaningful, right now.


>reverse engineering (if it is possible),

Reverse engineering is /always/ possible, in any language.


>and how D can be used to create viruses.

Even if I new the answer to that question, it would be highly irresponsible of me to answer it.

Arcane Jill

Arcane Jill wrote:

> In article <cibpov$2ejf$1@digitaldaemon.com>, Gold Dragon says...

>>and how D can be used to create viruses.
> 
> 
> Even if I new the answer to that question, it would be highly irresponsible of
> me to answer it.

The answer isn't really that dangerous:

The same as any other high-level general-purpose language.

One could however argue that due to the footprint of any D program being considerably larger that the footprint of a hand-assembled one, it'd have a great deal more difficulty propagating and escaping detection.

And in the end, virii are caused by gargantuan architectural flaws in the security model used by most modern operating systems. That an executable should be capable to editing every file on the HD *just* because the logged-in user can is preposterous. It's fairly depressing there exists a market for anti-virus software.

Cheers,
Sigbjørn Lund Olsen

In article <cibvum$2ibb$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cibpov$2ejf$1@digitaldaemon.com>, Gold Dragon says...
>
>>How can you secure D from hackers,
>
>Please could you be more specific in your question. It's a little too vague to be meaningful, right now.

The obvious issue that comes to mind is buffer overrun attacks (since they're such a hot topic these days).  D has built-in support for dynamic arrays and offers string.format (which can resize the buffer if needed) instead of sprintf, both of which reduce the likelyhood that an average program will be written in such a way that buffer attacks are possible (compared to C/C++).


Sean

In article <cic9hi$2oaa$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <cibvum$2ibb$1@digitaldaemon.com>, Arcane Jill says...
>>
>>In article <cibpov$2ejf$1@digitaldaemon.com>, Gold Dragon says...
>>
>>>How can you secure D from hackers,
>>
>>Please could you be more specific in your question. It's a little too vague to be meaningful, right now.
>
>The obvious issue that comes to mind is buffer overrun attacks (since they're such a hot topic these days).  D has built-in support for dynamic arrays and offers string.format (which can resize the buffer if needed) instead of sprintf, both of which reduce the likelyhood that an average program will be written in such a way that buffer attacks are possible (compared to C/C++).

Yes, I thought the original poster might have been referring to buffer overruns. Well then, D allows you to write low-level code, with the potential for low-level bugs. There is nothing to stop you, for example, calling the C function gets() - (viola - instant bug; instant security hole!).

It could be argued that the only way to avoid buffer overruns is to use a language which prohibits them, such as Java. However, just because D /allows/ you to write scary code, it doesn't /force/ you to do so. It's a systems programming language, with all the risks and responsibilities that go with that. Perhaps the bottom line is that if you're going to write a security app, you'd better know what you're doing. D does not claim to protect you from your own errors, and when it comes to security, every error is a potential hack-route.

Arcane Jill

In article <cie0th$ol8$1@digitaldaemon.com>, Arcane Jill says...
>It could be argued that the only way to avoid buffer overruns is to use a language which prohibits them, such as Java. However, just because D /allows/ you to write scary code, it doesn't /force/ you to do so.

Neither does C, but I'll bet just about every buffer overrun, every memory leak, and every faulty commercial program was written in C or C++.  Somehow, these programs always rear their ugly heads and threaten my data at crunch time.

I really think you're missing a fantastic opportunity here.  If I were to read that a program were written in a nice, simple language that absolutely prevents "scary" errors, I would definitely give it a second look.

For any critical use, if I had a choice, I wouldn't even consider a program that had any possibility of memory violations.

Yes, I know, you say you don't have to use the scary features (but claim that they are essential nonetheless).  That's not the point.  The point is that C programmers like these and will probably use them.  Lacking strong evidence to the contrary, from bitter experience I just assume that every program I buy is full of such bugs.

If you must retain unsafe features in D, you could at least isolate them to an unsafe system library.  If that library is not used, you could then certify the program as safe.

"Rex Couture" <Rex_member@pathlink.com> wrote in message news:cif54l$23ig$1@digitaldaemon.com...
> Neither does C, but I'll bet just about every buffer overrun, every memory
leak,
> and every faulty commercial program was written in C or C++.  Somehow,
these
> programs always rear their ugly heads and threaten my data at crunch time.
>
> I really think you're missing a fantastic opportunity here.  If I were to
read
> that a program were written in a nice, simple language that absolutely
prevents
> "scary" errors, I would definitely give it a second look.

The difference here is that to prevent buffer overruns in C, *extra* work is necessary on the part of the programmer. With D, one has to do extra work to get a buffer overrun. This pattern is fairly consistent: while D maintains the ability to use scary features, using them usually means the programmer has to do extra work, whereas the C programmer has to do extra work to avoid the problem.

In article <cif54l$23ig$1@digitaldaemon.com>, Rex Couture says...
>
>Yes, I know, you say you don't have to use the scary features (but claim that they are essential nonetheless).  That's not the point.  The point is that C programmers like these and will probably use them.  Lacking strong evidence to the contrary, from bitter experience I just assume that every program I buy is full of such bugs.
>
>If you must retain unsafe features in D, you could at least isolate them to an unsafe system library.  If that library is not used, you could then certify the program as safe.

D does array bounds checking, which is a significant step in the right direction.  I'm pretty sure the only means to cause a buffer overrun in D is to use pointers, which I expect to be quite uncommon in typical D programs.


Sean

In article <cif9iv$2c1g$1@digitaldaemon.com>, Walter says...
>...With D, one has to do extra work to
>get a buffer overrun. This pattern is fairly consistent: while D maintains
>the ability to use scary features, using them usually means the programmer
>has to do extra work....

Thanks.  That is a vast improvement.

In article <cifa5f$2d3u$1@digitaldaemon.com>, Sean Kelly says...
>...which I expect to be quite uncommon in typical D programs.

I was hoping for something more like total erradication.  Arcane Jill just gave us one simple scenario how such security holes will get in.  I'm confident that someone somewhere is going to use some treacherous C code or do something equally dumb.

D is a good start, but keep thinking security.  :-)