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 by Java and C# because it's "unsafe". 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