D array expansion and non-deterministic re-allocation

Bartosz Milewski bartosz-nospam at relisoft.com
Tue Nov 24 12:00:11 PST 2009


It's hard to argue whether something is or isn't bug prone and how severe the bugs could be. An experienced programmer knows all the gotchas so he or she will never introduce such bugs. A more bug-prone person will be afraid to speak up in public so as not to appear stupid or be bullied away. It's only when the language goes into production that the problems surface. Then an experienced programmer becomes part of a group or not so experienced programmers and he or she starts seeing how much the rests of the team is prone to certain bugs and how hard it is to prevent or even detect them. That's why the best languages attempt to turn as many errors as possible into hard bugs. 

Non-deterministic behavior is a major source of soft bugs. A buggy program might work correctly 99% of the time, introduce minor errors 0.9% of the time, and in 0.1% of the time lead to a disaster.

I will try to come up with some scenarios that would qualify for the "100 Gotchas with D arrays" to provide more food for though. Consider these little language puzzles. 

Imagine you're reviewing this code written by a relative newbee:

char[] quote(char[] word) {
  word.length += 2;
  word[length-1] = '"';
  for(int i = word.length-2; i > 0; --i)
    word[i] = word[i - 1];
  word[0] = '"';
  return word;
}

void storeFoos(char[] buffer, string pattern, Container c)
{
	char[] res = find(buffer, pattern);
	c.store(quote(res[0..pattern.len]);
}

Is this buggy? If so, how and when will the bug manifest itself? 

Or another story. An enthusiastic programmer comes to you with a very clever rewrite of a function. This is the original:

T[] duplicate(T)(T[] src) {
   static if (is(T == invariant))
      return src.idup;
   else
      return src.dup;
}

This is his improved version:

T[] duplicate(T)(T[] src) {
   T tmp = src[$-1];
   src.length -= 1;
   src ~= tmp;
   return src;
}

No need for static if! The extension is bound to re-allocate because of stomping rules. Will this always work, or is there a gotcha?




More information about the Digitalmars-d mailing list