Sorry for taking so long.

I agree with jwe that it might be better to handle for-loop expressions different from ranges elsewhere. And eventually remove ranges entirely in favor of vectors.
But IIUC, this change fixes an issue in the current implementation. Fixing that now in the way Petter proposed seems trivial compared to changing the interpreter like jwe proposed even if I like jwe's proposition better.
So, I pushed the patch here after some minor changes to coding style and the commit message:
https://hg.savannah.gnu.org/hgweb/octave/rev/355b4434b45d

Marking as ready for test.

'Instead, could we handle "EXP : EXP" and "EXP : EXP : EXP" as special cases in the interpreter instead of creating range objects?  Then it seems to me that we could handle integer base, increment, and limit values in FOR loops without needing the special data type.'

Construct like this one bellow maybe lead to problems with memory allocation if there is no lazy range object?

function foo
  for a = some_range()
  end
end

function r = some_range
  r = 1:1e9;
end

'Again, I encourage you to not focus so much on these kinds of issues until the bytecode interpreter is fully functional.'

Ye I agree. This patch is a bugfix and I explained why "trivial range" was done in the first place, i.e. for performance reasons.

I'm not convinced that we need a special data type for this job. 

Instead, could we handle "EXP : EXP" and "EXP : EXP : EXP" as special cases in the interpreter instead of creating range objects?  Then it seems to me that we could handle integer base, increment, and limit values in FOR loops without needing the special data type.

See also the various discussions we have had about eliminating the special range data type.  Matlab doesn't have one, so we don't need it in Octave for compatibility and it has caused a lot of trouble and confusion in the past.

In case this depends on whether an integer is representable as a double precision number, 2^53 might not be the universal upper limit. IIUC, it can be larger. E.g., if the base is a multiple of 2^N and the increment is 2^N, the integers can be represented correctly up to 2^(53+N).

Anyway, the "easy way out" would probably be to just use `octave_idx_type` here. Afaict, that is `int64_t`. That should be `long` on Linux or `long long` on Windows.
Imho, correct behavior might be more important than performance in this case.

Thank you for the patch.

Is there a particular reason why the "trivial range" is limitted to `int`? Would it make sense to use `octave_idx_type` for the range base and increment instead?