On Wednesday, 6 June 2012 at 23:10:54 UTC, Justin Whear wrote:
> On Thu, 07 Jun 2012 01:01:55 +0200, Alex Rønne Petersen wrote:
>
>> On 07-06-2012 00:04, J.Varghese wrote:
>>> I'm not a programmer, so can someone explain this to me: Will programs
>>> and operating systems written in D be safer (I speak of both memory
>>> safety and security bugs) than existing operating systems written in C
>>> and C++? If so, what features and attributes of D make this the case?
>>> How much safer is it? Would it be possible to identify all the bugs in
>>> an OS written in D (within a reasonable timeframe) or is that still a
>>> pipedream?
>>>
>>> Thanks for replying. I have followed the development of D for a while.
>>> I just want to know how much safer D is than other languages. Curiosity
>>> and all that.
>> 
>> No programming language (today) can make cryptosystems more or less
>> mathematically secure. ...
>> 
>> So what D does is that it prevents small but common exploits in
>> programs. But that doesn't mean that your program is cryptographically
>> sound/secure, for example.
>> 
>> As always, It Depends (TM). :)
>
> I'd add to this list a philosophy decision: D tries to make the correct
> way the easiest way and path of least resistance. A highly disciplined
> and skilled C coder could accomplish the effect, but practically
> speaking, this can help eliminate a class of errors due to programmer
> laziness or lack of understanding.
>
> Justin

The problem is that "skilled C coders" are very hard to find.

The company I work for does consultancy in JVM and .NET environments, and I cry every time I do code review in languages that are supposedly easy to master.

I cannot even imagine the type of code many of our developers would write in C or C++.

On Thu, 07 Jun 2012 06:47:05 +0100, Mehrdad <wfunction@hotmail.com> wrote:

> On Thursday, 7 June 2012 at 05:09:27 UTC, Alex Rønne Petersen wrote:
>> On 07-06-2012 07:04, Mehrdad wrote:
>>>> no programming language will save you from that
>>>
>>> LINQ isn't exactly susceptible to SQL injection. :P
>>
>> LINQ can't mutate the state of the DB, only query it. LINQ far from covers everything.
>
> True enough, although it's not too difficult to imagine an extension of LINQ where that is indeed possible.
>
> Nonetheless, the following /is/ called "LINQ to SQL" (why, I don't know):
> http://msdn.microsoft.com/en-us/library/bb386941.aspx

I've done some work with LINQ to SQL recently.  The reason that is labeled as such is that the DataContext object which is used in those examples is one generated by the LINQ architecture from a SQL database.  So, while this has nothing to do with LINQ style statements in code, it is related to the objects those statements are used on/with. :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

> D has a few language features that help to minimize exploits:
>
> - slices
> - bounds checking
> - more restrict type checking
> - GC
> - reference parameters
> - proper strings
> - security layers among modules (system, trusted, safe)
>
> Most C and C++ security exploits are due to:
>
> - pointer arithmetic
> - null terminated strings
> - lack of bounds checking on array access
> - usage of pointers to change input arguments
>
> Sure enough, static analysis tools can help, but not everyone makes
> use of them. Note that C++ library can help, but requires that the developers
> play by the rules.
>
> But no language is 100% full proof. You still need to take care data
> is properly handled (SQL, passwords, etc) and if the OS does not provide
> the proper security mechanisms, you can still tweak the assembly code.
>
> --
> Paulo


So if the causes of most C and C++ security exploits have been addressed in D and D makes it difficult to write insecure code, what exploits are still possible in D? Have the most serious and numerous bugs been made unlikely in D? Does anybody know if D makes new classes of bugs possible?

If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?

On Thursday, 7 June 2012 at 09:44:35 UTC, J.Varghese wrote:
> If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?

You should tell how many bugs in OSes are specific to C language level security.

On 6/6/2012 3:04 PM, J.Varghese wrote:
>
> I'm not a programmer, so can someone explain this to me: Will
> programs and operating systems written in D be safer (I speak of
> both memory safety and security bugs) than existing operating
> systems written in C and C++?

D offers a number of features designed to reduce and even eliminate security problems due to exploits of memory corruption issues. For example, @safe functions.

D does offer things like better encapsulation methods that enable the programmer to better define interfaces, such as contracts, but designing that for security would be entirely up to the programmer.

"J.Varghese" <unnecessary@unknown.com> wrote in message news:vcmamxcuyhiqigjrqnxf@forum.dlang.org...
>
> If I was comparing a C/C++ OS versus an identical OS written in D, do you have estimates for many fewer bugs the D OS will have? 20% fewer minor bugs? 50% fewer critical bugs? Is that even the right question to ask?

It's not that predictable. It all depends on the code, the programmers, the way the project's managed, all sorts of very non-quantifiable things. There's a lot about D that makes it easier to write code that's less buggy, and less prone to certain security issues, etc., but it's not something that can really be quantified like that, regardless of what two languages you're comparing.

> It's not that predictable. It all depends on the code, the programmers, the
> way the project's managed, all sorts of very non-quantifiable things.
> There's a lot about D that makes it easier to write code that's less buggy,
> and less prone to certain security issues, etc., but it's not something that
> can really be quantified like that, regardless of what two languages you're
> comparing.

Thanks. I understand better now.