[M3devel] [M3commit] CVS Update: cm3

[Rodney M. Bates]

Yes.  This is a wonderful example of a half bugfix.  Original code was

String8.FindCharR (i.start, MIN (i.length, start), c);

start is off by one here and needs to be increased by one, so I changed
it to

String8.FindCharR (i.start, MIN (i.length, start+1), c);

This is correct for every case except start=LAST(INTEGER), (which is
likely to happen because it is the defaulted value of parameter start).
Even so, I thought the MIN  function should take care of this, but the
intermediate value of start+1  overflows silently, wraps around to
FIRST(INTEGER), and becomes the minimum.   So now its:

String8.FindCharR (i.start, MIN (i.length-1, start)+1, c);

which can have the same problem on the low end, i.e., it can go
temporarily negative by one, but that is OK because the intermediate
arithmetic is done in INTEGER, and the final result will always end up
at least zero, within the needed range of CARDINAL.

This would make a good textbook example.

Jay wrote:
> Rodney, "it seems obvious" the problem was related to:
>  
> PROCEDURE Bar(start: INTEGER);
>  
>  PROCEDURE Foo(start := LAST(INTEGER)) = 
>  BEGIN 
>    Bar(start + 1); 
>  END Foo; 
>  
>  LAST(INTEGER) + 1 => error 
>  Though I grant, that is about all I looked at,
>    couldn't be much shallower of an analysis.
>  
>  
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: rodney.bates at wichita.edu
>> Date: Tue, 17 Feb 2009 13:57:17 +1100
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>
>> Yes, it would be good to get the bugfixes in separately from your
>> current new TEXT development branch.
>>
>> On 17 Feb 2009, at 04:57, Rodney M. Bates wrote:
>>
>>> No, the trunk right now is as it was before I started working on it,
>>> which, I believe, has been unchanged for years. I guess it's
>>> confusing,
>>> as my way of putting it back probably gives recent dates and new
>>> version
>>> numbers on everything.
>>>
>>> I guess I could backport the bug fixes into the trunk.
>>>
>>> Tony Hosking wrote:
>>>> Does the trunk still contain your bug-fixes?
>>