Refactor List.setRange function.

runtime/bin/process_patch.dart

Index: runtime/bin/process_patch.dart
diff --git a/runtime/bin/process_patch.dart b/runtime/bin/process_patch.dart
index 64828f50dd68eb36d500db6ca4a635d57b22b291..ae87f4e0e4edceed464cb69bb14153c7be7c7ff2 100644
--- a/runtime/bin/process_patch.dart
+++ b/runtime/bin/process_patch.dart
@@ -199,7 +199,7 @@ class _ProcessImpl extends NativeFieldWrapperClass1 implements Process {
           _stdin._sink.destroy();
         }
 
-        exitDataBuffer.setRange(exitDataRead, data.length, data);
+        exitDataBuffer.setRange(exitDataRead, exitDataRead + data.length, data);

[Lasse Reichstein Nielsen, 2013/04/11 06:11:55]

I still think it reads better as
  .setList(exitDataRead, data)
i.e., with signature
  .setList(int at, List source, [int start = 0, int end])
It won't be a "range" function on the destination, but it is acting on a range
of the source.

It avoids the common second argument of setRange(i, i + x.length, x).
As an extra bonus, it changes the signature to be incompatible with current
uses, instead of just changing the meaning of the second integer (that's
undetected bugs waiting to happen)

This is the low-level, efficient list copy. As such, it is in a sense not at the
same level of abstraction as the other "Range functions", and it would be more
obvious with a non-range name.

         exitDataRead += data.length;
         if (exitDataRead == EXIT_DATA_SIZE) {
           handleExit();