Walter:
> The slides: http://www.slideshare.net/dcacm/patterns-of-human-error
Nice. Please put your PDFs everywhere but Slideshare. I'd love a simple link to just the PDF, thank you very much (Slideshare requires Flash, JavaScript, other things, and the flash viever doesn't allow me copy&paste of URLs like that joelonsoftware.com one or snippets that I have to copy manually here).
-----------------
- 9V battery: it has keyd connectors *and* inverting its polarity often doesn't lead to large damages (you may damage the curcuit in some cases). This means that a car batter has to be designed *safer* than a 9V battery because an error often causes more damages than in 9V batteries.
-----------------
> Simple fix: make l suffix illegal. No more possibility of this error. End of story.
This is exactly the solution used by JSF-AV. They use a pre-compiler that generates a "compile" error if you use "l" as suffix (and maybe even if you use it as variable name). So they aren't using normal C++.
-----------------
> int i = 1_000_000;
A downside of the current implementation is visible here:
long i = 1_000_000_00_000L;
The underscores are not enforced every 3 (or 4 on hex/binary literals) digits.
But in practice this has not caused me troubles, so far.
-----------------
> Error Patterns Eliminated [Slide 32]
It's a very nice slide :-)
-----------------
> i should be size_t [Slide 31]
Something related to this has caused me a not immediately visible bug in D, this is the original correct function:
double[][] matgen(int n) {
double[][] a;
double tmp = 1.0 / n / n;
a.length = n;
for (int i = 0; i < n; ++i) a[i].length = n;
for (int i = 0; i < n; ++i)
for (int j = 0; j < n; ++j)
a[i][j] = tmp * (i - j) * (i + j);
return a;
}
Second "improved" version:
double[][] matgen(int n) {
double tmp = 1.0 / n / n;
auto a = new double[][](n, n);
foreach (i, row; a)
foreach (j, ref x; row)
x = tmp * (i - j) * (i + j);
return a;
}
Problem: (i - j) gives a wrong result because i and j are now unsigned.
See some of the discussion: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=26563http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=26587http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=26629
-----------------
> Uninitialized memory [Slide 41]
This compiles with no errors, but maybe you meant heap memory:
@safe void main() { int x = void; }
-----------------
> Validated data: validated!(T) [Slide 46]
I don't remember/know what this is.
Thank you for all this stuff you give us for free, people used to pay for such texts.
-----------------
> http://www.joelonsoftware.com/articles/wrong.html
From the blog post:
>All strings that come from the user must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known-safe location must be stored in variables with a name starting with the prefix "s" (for Safe string).
A better solution: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
Bye,
bearophile

On Fri, 6 May 2011, Walter Bright wrote:
> On 5/6/2011 8:13 AM, Andrej Mitrovic wrote:
> > Is that a typo on page 31?
> > > > "<= should be ="
> > > > maybe<= should be<
> > > > I guess that further drives the point though. :)
> > You're right. Good catch.
That was the first error I caught.. since I've seen you use it as a common error and reason to use foreach() style loops before.