www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Memory Safety

reply Walter Bright <newshound1 digitalmars.com> writes:
Reddit:

http://reddit.com/info/6cymv/comments/

Dr. Dobbs:

http://dobbscodetalk.com/index.php?option=com_myblog&show=Memory-Safety.html&Itemid=29
Mar 21 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
It's good to have a place like that where you are free to talk about all the
interesting things you like :-)
Java seems good in that regard :-)

Walter:

since D is a powerful programming language even without pointers, it may be
practical to define a safe D subset. We are examining each feature of D to find
the largest possible subset of the language that is memory safe. Then, if this
subset is itself a practical language, D can be a major contribution towards
eliminating malware.<


So you need a tool to see if some D code is using just that subset, I presume
this isn't too much difficult to do.

So the questions are:
- Is such D subset useful/enough in practice?
- Is such subset any better than Java itself?
- Even if such subset of D is useful, and it's better than Java, are enough
people going to use it (instead of Java, or instead of full D) so it can become
a "major contribution" in practice too? :-)

Thank you very much for the interesting topic,
bearophile
Mar 21 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 It's good to have a place like that where you are free to talk about all the
interesting things you like :-)
 Java seems good in that regard :-)
 Walter:

since D is a powerful programming language even without pointers, it may be
practical to define a safe




D subset. We are examining each feature of D to find the largest possible
subset of the language that is
memory safe. Then, if this subset is itself a practical language, D can be a
major contribution towards
eliminating malware.<

 So you need a tool to see if some D code is using just that subset, I presume
this isn't too much difficult


to do.

Walter has talked about this before.  Search old posts in this NG for more
info.  I'd point you at a post, but
it'd take me a while to find it and I'm on my way out of the office.


Sean
Mar 21 2008
prev sibling next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:

 Reddit:
 
 http://reddit.com/info/6cymv/comments/
 
 Dr. Dobbs:
 
 http://dobbscodetalk.com/index.php?option=com_myblog&show=Memory-S
fety.html&Itemid=29 


Good article!

Off-hand one can see applications in banking, tcp (including the WWW), 
even military stuff. Actually anything where an app is expecting 
specific input while at risk of getting arbitrary input instead. This 
may be due to malice, sloppy users, or various hiccups. While this of 
course isn't equivalent to correct-proven software, it gives us yet 
another avenue where we could beat C++ on the head.

I'm looking forward to the day when DMD has a switch to check this!
Mar 21 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Here's Bartosz' article on the subject:

http://www.digitalmars.com/d/2.0/safed.html
Mar 21 2008
next sibling parent reply davidl 126.com writes:
在 Sat, 22 Mar 2008 09:34:28 +0800，Walter Bright  
<newshound1 digitalmars.com> 写道:


 Here's Bartosz' article on the subject:

 http://www.digitalmars.com/d/2.0/safed.html


So D is going towards totally anti-JIT ?
As far as I can see, JIT uses technology of constructing user data and  
executing them. I think this D subset still leaves a dirty way which need  
to be declared explicitly to allow executing JIT compiler's output.


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Mar 22 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
davidl 126.com wrote:

 So D is going towards totally anti-JIT ?


I don't know what you mean by that.


 As far as I can see, JIT uses technology of constructing user data and 
 executing them. I think this D subset still leaves a dirty way which 
 need to be declared explicitly to allow executing JIT compiler's output.
Mar 22 2008
parent davidl <davidl 126.com> writes:
鍦 Sun, 23 Mar 2008 01:42:23 +0800锛學alter Bright  
<newshound1 digitalmars.com> 鍐欓亾:


 davidl 126.com wrote:

 So D is going towards totally anti-JIT ?


 I don't know what you mean by that.


I thought D is going to be the cut to the subset of D. Recently I get  
informed that it will be a compiler option. There everything goes fine. :D


 As far as I can see, JIT uses technology of constructing user data and  
 executing them. I think this D subset still leaves a dirty way which  
 need to be declared explicitly to allow executing JIT compiler's output.






-- 
浣跨敤 Opera 闈╁懡鎬х殑鐢靛瓙閭欢瀹㈡埛绋嬪簭: http://www.opera.com/mail/
Mar 23 2008
prev sibling next sibling parent davidl 126.com writes:
在 Sat, 22 Mar 2008 09:34:28 +0800，Walter Bright  
<newshound1 digitalmars.com> 写道:


 Here's Bartosz' article on the subject:

 http://www.digitalmars.com/d/2.0/safed.html



"its front end is in the public domain" <-- this is probably a wrong  
statement ?


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Mar 22 2008
prev sibling parent renoX <renosky free.fr> writes:
Walter Bright a 閏rit :

 Here's Bartosz' article on the subject:
 
 http://www.digitalmars.com/d/2.0/safed.html


Very interesting, I thought that D could be left out in many situation 


I'm wondering if this 'safe' subset of D would be able to use a moving GC?

Regards,
renoX

PS:
I find quite funny that the article emphasize the 'horrible C++ syntax' 
and then talk about D: D's syntax is better sure, but in comparison to 
Scala, it's not that good..
Mar 22 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Here's Bartosz' article on the subject:
 http://www.digitalmars.com/d/2.0/safed.html


Bartosz Milewski about SafeD:


The pipe dream of programming language designers is to be able to guarantee
that if a program compiles successfully, it will work.<


I think Haskell language is already a bit closer to this goal than most other
languages. But that's a pipe dream only of some programming language designers.
I assure you that other language designers have different purposes. There are
lots of languages (Lisp, Smalltalk, Python, Ruby, Lua, Boo, Perl, etc) that
have success, often a wide success, despite their designers don't have that
purpose.



why anyone would want to switch to a less powerful and less efficient language.<


Note that some languages are "more powerful" than C++. Haskell type system or
Lisp macros allow you to do things in a short space that you will have a hard
time doing in C++. C++ type system is full of holes. Python dynamic typing
allows you to do many things you don't even dream about in your usual C++
programs, etc.



What are the major impediments to productive programming in C++?<


Well, starting from the most important ones:
- Too many corner cases and corner cases of the corner cases, etc
- Too many things to remember and to think about
- Not enough user-friendly
- Bad syntax
- It keeps various design mistakes of C
- Too much unsafe
- Forces you to always focus on too much little details, even in situations
where your code is I/O bound, or user-interface-speed bound, etc, where the
slowest scripting language too may be enough.
- Not dynamic enough for some purposes
- etc



once somebody invested the time and effort to become proficient in C++, why in
the world would they want to abandon it?<


More productivity is one answer, but it's not the whole answer, and even
"productivity" means little if you don't decompose it into its parts.
Programming in other languages is or may be:
- faster
- more fun
- safer (less bugs, etc).
- requires less brain/memory
- etc.

I think that in many situations D is currently more productive than C++, but it
has many problems still, and it can be improved in many ways still.
A higher "productivity" comes from many different things, it doesn't come from
a single thing. D can't be as productive as Python, because their purpose is
different. Python has dynamic typing, it's a huge programming speed boost, but
beside a really good duck (variant) type that can be added in future (example:
it must allow me to nest arrays of duck as much as I want), D will keep being
statically typed (and I like it that way). Python is designed for the
programmer first, to have the best possible syntax, Python designers think that
a better syntax and a better language is more important than running speed. So
it's normal that programming in Python is faster and produces less bugs and it
feels more fun, etc. This is true for Ruby too, usually.

To increase D "productivity" various things may to be fixed/improved:
- I think the single most important thing is to avoid corner cases. D has quite
less corner cases than C++, but I have found many of them still, you can see
some of them in some of my posts. A long-term hunt has to begin, to find them
and to remove as much of them as possible, this is very useful if D wants to
become a safer language. I think a safer language is the first thing that
allows you higher "productivity". At the moment I think this work is more
important than even adding AST macros to D. AST macros are a cool feature, that
surely works as a D advertisement, to attract new people, while "D has 1/100 of
the corner cases of C++ and only 15 times as much as Python" is a much less
sexy advertisement, but I think it will make those new people *keep* using D in
the medium/long run.
- In one of my posts I have shown that the current D module system has various
holes, but it can be fixed. Python 3.0 shows how it can be designed. If copying
Python 3.0 module system is seen as a bad/boring thing, then a totally
different module system can be designed, but it must be sound anyway, unlike
the current one. A fixed module system will avoid some problems and bugs.
- Using integrals in D is a mine field still. Here you can find some pages
about C and C++ that show some of the things a compiler must do to improve the
situation:
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6422581

https://www.securecoding.cert.org/confluence/display/seccode/INT30-C.+Do+not+perform+certain+operations+on+questionably+signed+results

https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensure+that+integer+operations+do+not+result+in+an+overflow

Another improvement comes from adding pointer and integer overflow controls,
like in Pascal and Lisp, this lib may be automatically used by the compiler
when the code isn't in release mode:
http://www.cert.org/secure-coding/IntegerLib.zip
[Python is more productive than C++ also because you (usually) can't overflow
Python integers, this avoids a ton of problems, and you don't have to care
about those things, so you can speed up your programming style.]
- Some parts of the syntax can be improved and shortened, like the is() syntax,
lambda syntax, etc.
- D is somewhat C-compatible, but C has various warts/problems. So if D wants
to be better, it can't avoid being different regarding some things. Some of the
things that make numerical computation in C a minefield:
-- negation does not turn negative numbers into positive ones in 2s complement
math
-- C does not define the shift value to be saturating
-- C does not enforce the definition of sign right shifting
-- In the case of (signed int)a % (unsigned int)b, the cast value of a is first
promoted to an unsigned int, then the modulo is computed. This will lead to
unintended results whenever (signed int)a is negative (the result will not be
congruent to (signed int)a modulo (unsigned int)b).
-- etc.
- One last thing: if I use a language that is 30% slower than D (so it has a
better syntax, it's higher level, etc), but it allows me to use both the cores
of the CPU for many parts of my program, then the program may end up running
faster anyway. So D has to focus on parallel programming too.
ParallelPascal/VectorPascal and Fortress show some "simple" ways where D can be
improved in such regard.

This is just a little list of things, but I think it's enough to show that
there's no silver bullet to increase "productivity". Still, D has many ways to
increase it in its future, keeping most of its running speed.

Bye,
bearophile
Mar 22 2008