21-Jul-2014 02:29, Walter Bright пишет:
On 7/20/2014 3:10 PM, Dmitry Olshansky wrote:
The computed goto is faster for two reasons, according to the article:
1.The switch does a bit more per iteration because of bounds checking.
Now let's consider proper implementation of thread-code
On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
The point is - software that only works in release build is kind of hard to
develop, even more so with libraries. Thus I'm in opposition to labeling such
things as optimization when they, in fact, change semantics.
-release, -inline, -O and -g are
24-Jul-2014 00:14, Walter Bright пишет:
On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
The point is - software that only works in release build is kind of
hard to
develop, even more so with libraries. Thus I'm in opposition to
labeling such
things as optimization when they, in fact, change
On 7/23/2014 1:20 PM, Dmitry Olshansky wrote:
Unless you are library writer, and then it's user who mixes and matches flags
and you are foobared unless it works with them all :)
I think it's a generally unworkable rabbit hole if we add language features to
turn on/off various optimizations.
24-Jul-2014 00:43, Walter Bright пишет:
On 7/23/2014 1:20 PM, Dmitry Olshansky wrote:
Unless you are library writer, and then it's user who mixes and
matches flags
and you are foobared unless it works with them all :)
I think it's a generally unworkable rabbit hole if we add language
features
Dmitry Olshansky:
(unlike compute-goto which is very niche and dangerous).
It's a niche that system languages are the few fit for. Even
CPython (and other interpreters) are using that feature.
Bye,
bearophile
24-Jul-2014 01:05, bearophile пишет:
Dmitry Olshansky:
(unlike compute-goto which is very niche and dangerous).
It's a niche that system languages are the few fit for. Even CPython
(and other interpreters) are using that feature.
All of fast portable interpreters i.e. not JITs.
It's still
On 7/23/14, 1:14 PM, Walter Bright wrote:
On 7/23/2014 1:06 PM, Dmitry Olshansky wrote:
The point is - software that only works in release build is kind of
hard to
develop, even more so with libraries. Thus I'm in opposition to
labeling such
things as optimization when they, in fact, change
On 7/23/2014 1:53 PM, Dmitry Olshansky wrote:
Obviously optimizations won't solve this problem, with that said it would be
awesome to have your 2 final switch enhancements.
Yes. Feel free to ping me if I forget about them.
Also, I particularly like the first of them because it's not available
On 7/23/14, 2:41 PM, Walter Bright wrote:
On 7/23/2014 1:53 PM, Dmitry Olshansky wrote:
Obviously optimizations won't solve this problem, with that said it
would be
awesome to have your 2 final switch enhancements.
Yes. Feel free to ping me if I forget about them.
bugzilla -- Andrei
On 7/23/2014 2:42 PM, Andrei Alexandrescu wrote:
On 7/23/14, 2:41 PM, Walter Bright wrote:
On 7/23/2014 1:53 PM, Dmitry Olshansky wrote:
Obviously optimizations won't solve this problem, with that said it
would be
awesome to have your 2 final switch enhancements.
Yes. Feel free to ping me if
On 07/22/2014 05:02 AM, Walter Bright wrote:
On 7/21/2014 3:25 PM, Timon Gehr wrote:
The example just uses the ST Monad which is quite similar to weakly pure
statements in D.
D doesn't have weakly pure statements - it has weakly pure functions.
The type checker distinguishes between
On Monday, 21 July 2014 at 22:10:06 UTC, bearophile wrote:
Tobias Müller:
Wouldn't it be more useful to have a modified/annotated return
statement for that?
I don't know.
I see what you're saying, and it works for the quick sort
example. I'm not sure it covers all tailrec cases, but it
My understanding is that it can be done
but only with annotations or whole program analysis.
I think that's true but you don't necessarily have to annotate
every function.
a) possibly there's something interesting to do at the module
level. I think more than one thing. E.g. A module that
On 7/21/14, 3:22 PM, Timon Gehr wrote:
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote:
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice
On 07/22/2014 05:49 PM, Andrei Alexandrescu wrote:
On 7/21/14, 3:22 PM, Timon Gehr wrote:
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote:
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
...
D has loops, even in pure functions,
So does Haskell.
import
Timon Gehr:
It is easy to understand and
It's easy to understand because you are very intelligent Timon :-)
Bye,
bearophile
On 7/20/2014 8:15 PM, Timon Gehr wrote:
So does Haskell.
import Control.Monad
import Control.Monad.ST
import Data.STRef
factorial :: Integer - Integer
factorial n = runST $ do
r - newSTRef 1
forM_ [1..n] $ \i-
modifySTRef r (*i)
readSTRef r
Would you rather write that or:
Walter Bright:
Would you rather write that or:
How much experience do you have in writing Haskell programs
longer than 50 lines of code? I have a large respect for your
experience and your intelligence, but be careful with comments
like that, to not show just your ignorance...
If you are
On Tue, Jul 22, 2014 at 11:34:20AM -0700, Walter Bright via Digitalmars-d wrote:
On 7/20/2014 8:15 PM, Timon Gehr wrote:
So does Haskell.
import Control.Monad
import Control.Monad.ST
import Data.STRef
factorial :: Integer - Integer
factorial n = runST $ do
r - newSTRef 1
forM_
On 7/22/2014 11:44 AM, bearophile wrote:
Walter Bright:
Would you rather write that or:
How much experience do you have in writing Haskell programs longer than 50 lines
of code?
Zero.
I have a large respect for your experience and your intelligence, but
be careful with comments like
On Tuesday, 22 July 2014 at 19:12:31 UTC, H. S. Teoh via
Digitalmars-d wrote:
I'd rather write:
int factorial(int n) pure {
return reduce!((a,b) = a*b)(1, iota(2, n));
}
;-)
This is how we fucked UFCS.
On 07/22/2014 08:34 PM, Walter Bright wrote:
On 7/20/2014 8:15 PM, Timon Gehr wrote:
So does Haskell.
import Control.Monad
import Control.Monad.ST
import Data.STRef
factorial :: Integer - Integer
factorial n = runST $ do
r - newSTRef 1
forM_ [1..n] $ \i-
modifySTRef r (*i)
On 07/22/2014 09:42 PM, Walter Bright wrote:
On overall I prefer D over Haskell, but if you want to criticize
Haskell you
need much much better arguments and way bigger cannons :-)
The point was not at all to criticize Haskell. The point was that D does
not need tail recursion because D
On 07/22/2014 11:23 PM, Timon Gehr wrote:
Looping is not the main reason for supporting tail calls.
(In D!)
Timon Gehr:
What do you think would be the corresponding idiomatic/fast D
code? Does it outperform the Haskell code?
Look in RosettaCode for various implementations in D:
http://rosettacode.org/wiki/Hamming_numbers#D
A good part of the performance difference is caused by the D GC
and the
On 7/22/2014 2:23 PM, Timon Gehr wrote:
On 07/22/2014 09:42 PM, Walter Bright wrote:
Showing how loops could be written using awkward
The point is not to criticize? :-)
Yes. If you want to infer criticism of Haskell from that, go ahead, but none was
intended. You can write awkward code in
On 7/22/2014 2:29 PM, bearophile wrote:
A good part of the performance difference is caused by the D GC and the fact
that Haskell GHC uses a the GNU multiprecision libs for its bigsint. In the
meantime we have to maintain, optimize and debug our bigint implementation,
wasting time better spent
On 7/22/2014 2:08 PM, Timon Gehr wrote:
And I'd love to see what native code is generated for the Haskell example.
Well, the _actually_ corresponding D code using BigInt and DMD is significantly
slower than what GHC generates here.
Irrelevant to the looping issue - comparing the code gen of
On 07/23/2014 12:14 AM, Walter Bright wrote:
Sure, that part of the discussion grew out of the claim that there are
no
loops there.
Bending a language over backwards
Not what happened.
to be pedantic
Being pedantic is important enough.
is pointless for this discussion.
If one
On Tuesday, 22 July 2014 at 21:23:33 UTC, Timon Gehr wrote:
On 07/22/2014 09:42 PM, Walter Bright wrote:
The point was not at all to criticize Haskell. The point was
that D does
not need tail recursion because D supports writing loop
constructs.
Tail call support is still useful. Looping is
On Sunday, 20 July 2014 at 06:06:16 UTC, bearophile wrote:
Andrew Godfrey:
2) Annotations about when a function does not expect
re-entrancy
to be possible based on call-graph analysis.
I don't understand. Assuming I know tAhis
(http://en.wikipedia.org/wiki/Reentrancy_%28computing%29 ) can
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so must do recursion. D has
loops, even in pure functions, there's no reason not to use
On 7/20/2014 1:50 PM, Walter Bright wrote:
Both of these are worthy of bugzilla enhancement requests.
Amazingly, these suddenly appeared:
https://issues.dlang.org/show_bug.cgi?id=13169
https://issues.dlang.org/show_bug.cgi?id=13170
Walter Bright:
https://issues.dlang.org/show_bug.cgi?id=13169
https://issues.dlang.org/show_bug.cgi?id=13170
Are such optimizations portable and guaranteed on all D
compilers? If the answer is negative, then they can't replace a
_standard_ D syntax for computed gotos.
Bye,
bearophile
On 7/20/2014 3:10 PM, Dmitry Olshansky wrote:
The computed goto is faster for two reasons, according to the article:
1.The switch does a bit more per iteration because of bounds checking.
Now let's consider proper implementation of thread-code interpreter.
where *code pointer points to an
21-Jul-2014 00:50, Walter Bright пишет:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so must do recursion. D
has loops, even in pure
On 7/20/2014 2:38 PM, bearophile wrote:
Are such optimizations portable and guaranteed on all D compilers? If the answer
is negative, then they can't replace a _standard_ D syntax for computed gotos.
C'mon, bearophile. Optimizations are always implementation dependent. People
rely on them for
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so must do recursion.
Uh...
D has loops,
On 7/20/2014 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Traditional FP languages don't have loops, and so
On Sunday, 20 July 2014 at 07:27:36 UTC, Walter Bright wrote:
What about the @continuation
(http://en.wikipedia.org/wiki/Continuation-passing_style )?
I doubt they'll want to use that attribute, either.
Especially if that can be done with AST macros :D
Andrew Godfrey x...@y.com wrote:
1) A function annotation that means I will call myself
recursively, and when I do, I expect the tail recursion
optimization. I have seen code which allocates something big on
the stack and depends on the optimization. So this intent should
be expressible.
Tobias Müller:
Wouldn't it be more useful to have a modified/annotated return
statement for that?
I don't know.
Tail-recursiveness is an implementation detail, for the user of
the function it's not really interesting.
Yes, in theory a @tailrec annotation doesn't change the mangling
of
On 07/21/2014 06:40 AM, Andrei Alexandrescu wrote:
On 7/20/14, 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
On 07/21/2014 06:56 AM, Walter Bright wrote:
On 7/20/2014 8:15 PM, Timon Gehr wrote:
On 07/20/2014 10:50 PM, Walter Bright wrote:
On 7/20/2014 3:27 AM, Dmitry Olshansky wrote:
Functional programming is full of simple recursion and it would be
nice not to
stack overflow in debug builds.
Andrei Alexandrescu:
And that doesn't look awkward at all :o). -- Andrei
A related thread:
http://stackoverflow.com/questions/6622524/why-is-haskell-sometimes-referred-to-as-best-imperative-language
Bye,
bearophile
On 07/22/2014 12:10 AM, bearophile wrote:
Except for the fact that it has bounded stack size which is a useful
property by itself and not only for tailrecursive functions.
Yes, that's why I have said that a @continuation is a more general
solution than @tailrec.
Bye,
bearophile
On 7/21/2014 3:25 PM, Timon Gehr wrote:
The example just uses the ST Monad which is quite similar to weakly pure
statements in D.
D doesn't have weakly pure statements - it has weakly pure functions.
Andrew Godfrey:
1) A function annotation that means I will call myself
recursively, and when I do, I expect the tail recursion
optimization. I have seen code which allocates something big on
the stack and depends on the optimization. So this intent should
be expressible.
A @tailrec annotation
Andrew Godfrey:
1) A function annotation that means I will call myself
recursively, and when I do, I expect the tail recursion
optimization. I have seen code which allocates something big
on
the stack and depends on the optimization. So this intent
should
be expressible.
A @tailrec
On 7/19/2014 11:06 PM, bearophile wrote:
A @tailrec annotation seems good, and will improve the functional usages of D.
It should stop compilation with a error if the function doesn't call itself or
if the compiler is not able to remove the recursive call. This means it has to
be fully enforced.
Walter Bright:
If you want to guarantee replacement of a recursive call with a
loop, just write a loop.
There are cases where a recursive algorithm is nicer. And people
that want to use D functionally, may also be used to writing code
recursively.
What about the @continuation
On 7/19/2014 11:55 PM, bearophile wrote:
Walter Bright:
If you want to guarantee replacement of a recursive call with a loop, just
write a loop.
There are cases where a recursive algorithm is nicer. And people that want to
use D functionally, may also be used to writing code recursively.
I
20-Jul-2014 10:45, Walter Bright пишет:
On 7/19/2014 11:06 PM, bearophile wrote:
A @tailrec annotation seems good, and will improve the functional
usages of D.
It should stop compilation with a error if the function doesn't call
itself or
if the compiler is not able to remove the recursive
Walter Bright:
I doubt they'll want to use an @tailrec attribute.
In Scala there is @tailrec:
http://www.scala-lang.org/api/current/scala/annotation/tailrec.html
In both F# and OcaML there is the rec keyword:
http://msdn.microsoft.com/en-us/library/dd233232.aspx
Returning to the earlier question, of helping to avoid stack
overflows:
I can easily think of two things the language could do.
(Forgive me if D already has them - I have read a fair amount but
not all the minutiae.)
1) A function annotation that means I will call myself
recursively, and when I
On Sunday, 13 July 2014 at 23:35:46 UTC, Walter Bright wrote:
On 7/13/2014 4:04 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 13 July 2014 at 03:25:08 UTC, Walter Bright wrote:
On 7/11/2014 10:28 AM, deadalnix wrote:
The compiler can ensure that you hit at least every 4k or so.
And it
On 7/14/2014 3:07 AM, Marc Schütz schue...@gmx.net wrote:
Hmm... but this using DMD, not GDC. Or do you mean that DMD doesn't do it,
because GCC doesn't do it either?
Right.
If so, what is the reason for this? Why
shouldn't this feature be enabled on every platform?
There are often
On 14 July 2014 11:07, via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sunday, 13 July 2014 at 23:35:46 UTC, Walter Bright wrote:
On 7/13/2014 4:04 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 13 July 2014 at 03:25:08 UTC, Walter Bright wrote:
On 7/11/2014 10:28 AM, deadalnix
On Sunday, 13 July 2014 at 03:25:08 UTC, Walter Bright wrote:
On 7/11/2014 10:28 AM, deadalnix wrote:
The compiler can ensure that you hit at least every 4k or so.
And it already does.
Doesn't look so:
int foo(int a) {
int[100] b = void;
b[$-1] = a;
return
On 7/13/2014 4:04 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 13 July 2014 at 03:25:08 UTC, Walter Bright wrote:
On 7/11/2014 10:28 AM, deadalnix wrote:
The compiler can ensure that you hit at least every 4k or so.
And it already does.
Doesn't look so:
int bar(int a) {
On Friday, 11 July 2014 at 17:28:39 UTC, deadalnix wrote:
The compiler can ensure that you hit at least every 4k or so. It
doesn't look like a very hard constraint to have a volatile load
per untouched 4k of stack (which should be very rare).
Sure, it should be possible to work it into the
On 7/11/2014 10:28 AM, deadalnix wrote:
The compiler can ensure that you hit at least every 4k or so.
And it already does.
On Monday, 30 June 2014 at 08:00:37 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 26 June 2014 at 09:35:20 UTC, Walter Bright wrote:
Stack overflows are not safety problems when a guard page is
used past the end of the stack. Then, overflow checking is
done in hardware. Guard pages aren't
(Sorry for the very late answer.)
Walter Bright:
Stack overflows are not safety problems when a guard page is
used past the end
of the stack.
It's not a safety problem in Erlang/Rust, because those
languages are designed to manage such failures in a good way.
Please explain.
The idea
(Sorry for the very delayed answers.)
Walter Bright:
Oh well, there goes about 90% of D programs and pretty much all
use of the D runtime library!
Right. On the other hand the need for such strict safety
requirements that forbid stack overflows, is not present in
desktop
On 7/10/2014 5:08 AM, bearophile wrote:
(Sorry for the very late answer.)
Walter Bright:
Stack overflows are not safety problems when a guard page is used past the end
of the stack.
It's not a safety problem in Erlang/Rust, because those languages are
designed to manage such failures in a
On Thursday, 26 June 2014 at 09:35:20 UTC, Walter Bright wrote:
Stack overflows are not safety problems when a guard page is
used past the end of the stack. Then, overflow checking is done
in hardware. Guard pages aren't currently used for fibers, so
overflows are a real danger there.
But a
On Thursday, 26 June 2014 at 21:01:40 UTC, Araq wrote:
Spark is a research language that does not work, as I've
discovered and discussed with you before. It cannot be
determined the max stack usage at compile time, again, this is
the halting problem.
What?! It's easily solvable: Forbid
Am 29.06.2014 11:07, schrieb ponce:
On Thursday, 26 June 2014 at 21:01:40 UTC, Araq wrote:
Spark is a research language that does not work, as I've discovered
and discussed with you before. It cannot be determined the max stack
usage at compile time, again, this is the halting problem.
On Thursday, 26 June 2014 at 09:35:20 UTC, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the
halting problem. It needs a runtime check.
No, is N bytes of stack is
Walter Bright:
It's an interesting list, and an opportunity for D. I once said
that my job was to put Coverity out of business.
Even if D has wide success, I don't think D will delete all the C
and C++ code out of existence, so I don't think D will ever put
Coverity out of business :-)
Walter Bright:
It's an interesting list, and an opportunity for D. I once said
that my job was to put Coverity out of business. The more of
these issues D can automatically prevent with @safe, the better.
One kind of problem left is to avoid stack overflows. I have had
several such cases in
On Thursday, 26 June 2014 at 00:36:58 UTC, Walter Bright wrote:
http://samate.nist.gov/SRD/view.php?count=20first=0sort=asc
This is a list of security vulnerabilities in languages
including C/C++. 88,737 of them (!).
It's an interesting list, and an opportunity for D. I once said
that my
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting problem. It
needs a runtime check.
Stack overflows are not safety problems when a guard page is used past the end
of the stack.
Walter Bright:
In general, stack overflow checking at compile time is the
halting problem. It needs a runtime check.
There are several systems, including SPARK, that perform a
conservative and apparently acceptable stack overflow check at
compile time. If you don't agree with what I've
On 06/26/2014 11:35 AM, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting
problem.
That is irrelevant to his point because he is not suggesting to solve
the
On 6/26/2014 2:50 AM, bearophile wrote:
Walter Bright:
In general, stack overflow checking at compile time is the halting problem. It
needs a runtime check.
There are several systems, including SPARK, that perform a conservative and
apparently acceptable stack overflow check at compile time.
On 6/26/2014 2:52 AM, Timon Gehr wrote:
On 06/26/2014 11:35 AM, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting
problem.
That is irrelevant to his point
Spark is a research language that does not work, as I've
discovered and discussed with you before. It cannot be
determined the max stack usage at compile time, again, this is
the halting problem.
What?! It's easily solvable: Forbid recursion and indirect
function calls and it's guaranteed
On 6/26/2014 2:01 PM, Araq wrote:
Spark is a research language that does not work, as I've discovered and
discussed with you before. It cannot be determined the max stack usage at
compile time, again, this is the halting problem.
What?! It's easily solvable: Forbid recursion and indirect
On 06/26/2014 10:29 PM, Walter Bright wrote:
On 6/26/2014 2:52 AM, Timon Gehr wrote:
On 06/26/2014 11:35 AM, Walter Bright wrote:
On 6/26/2014 2:19 AM, bearophile wrote:
One kind of problem left is to avoid stack overflows.
In general, stack overflow checking at compile time is the halting
On 6/26/14, 2:01 PM, Araq wrote:
Spark is a research language that does not work, as I've discovered
and discussed with you before. It cannot be determined the max stack
usage at compile time, again, this is the halting problem.
What?! It's easily solvable: Forbid recursion and indirect
On 6/26/14, 4:16 PM, Timon Gehr wrote:
- Annotations can include a formal proof.
If a function can be annotated with what other functions it calls
(non-transitively), I agree that it can be guaranteed with local
semantic checking that a program won't overflow. However requiring such
On Thu, Jun 26, 2014 at 04:43:33PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/26/14, 2:01 PM, Araq wrote:
Spark is a research language that does not work, as I've discovered
and discussed with you before. It cannot be determined the max stack
usage at compile time, again, this
On 06/27/2014 01:47 AM, Andrei Alexandrescu wrote:
On 6/26/14, 4:16 PM, Timon Gehr wrote:
...
You can say out of scope or not a priority or this should be
realized in third-party tool support but not it is impossible.
I also seem to reckon Walter is in the other extreme (he asserts it
can't
On Thu, Jun 26, 2014 at 04:47:24PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/26/14, 4:16 PM, Timon Gehr wrote:
- Annotations can include a formal proof.
If a function can be annotated with what other functions it calls
(non-transitively), I agree that it can be guaranteed
On 6/26/2014 4:16 PM, Timon Gehr wrote:
On 06/26/2014 10:29 PM, Walter Bright wrote:
When you're dealing with security issues, which is what this about,
This is about _avoiding stack overflows_. It's written down literally in the
quoted passage.
Check the title of this thread, the linked
On 6/26/14, 5:29 PM, Timon Gehr wrote:
On 06/27/2014 01:47 AM, Andrei Alexandrescu wrote:
On 6/26/14, 4:16 PM, Timon Gehr wrote:
...
You can say out of scope or not a priority or this should be
realized in third-party tool support but not it is impossible.
I also seem to reckon Walter is in
On Thursday, 26 June 2014 at 09:19:05 UTC, bearophile wrote:
Walter Bright:
It's an interesting list, and an opportunity for D. I once
said that my job was to put Coverity out of business. The more
of these issues D can automatically prevent with @safe, the
better.
One kind of problem left
http://samate.nist.gov/SRD/view.php?count=20first=0sort=asc
This is a list of security vulnerabilities in languages including C/C++. 88,737
of them (!).
It's an interesting list, and an opportunity for D. I once said that my job was
to put Coverity out of business. The more of these issues D
92 matches
Mail list logo
