about check number heuristics

[Ethy H. Brito]

On Thu, 25 Jan 2007 10:00:54 -0500
Derek Atkins <warlord at MIT.EDU> wrote:

> >> Are you offering to code this and send in a patch?  :-D
> >>
> >
> > yes I am. In fact I am working on the idea reading the code to catch your
> > programing style and propose something that fits in.
> 
> Cool!  I look forward to your patch.  :)

Here go my thoughts:

I think the "problem" has to be dealed at check number increment/decrement.
If this is done correctly, the import matching do not have to be smart
(a simple str[n]cmp will do the job as it is today)
Please correct me. I have no deep knowledge of GC innards.

Then I thought about a print function.
It may deal with some format string and parse whatever the user writes, formatting accordingly something like this:

1- print numbers against a (C like) pattern

      c - alfabetic chars from A to Z
      h - alfabetic chars from 0 to 9 and from A to F
      d - alfabetic chars from 0 to 9
      u - a user defined ASCII sequence (in any order) up to 36 chars

      As examples printing decimal number 123 under the format string:
         "dddddd"       -> 000123 
         "dddcdddddd"   -> 000A000123 (also number 123. "A" is equiv. to 0)
         
      In this last example we have three groups:
         the first with 3 digits
         the secont: a single alphabetic char
         the third: 6 digits

2-    Each group of identical type will be inc/decremented separately 
      adding the carry bit from the group at its left

      For instance the format string "ddd ccddd" will give us 
      "000 ZZ999" + 1 = "001 AA000" 
      (just for fun: don't have any ideia what "000 ZZ999" decimal number is)

3-    Some flags may controls when strip leading zeroes from target or
      to honor the carry from previous operations.

4-    Overflows/wrapping are governed by each field length

Too complex? Any hard impacts on GC as it is now?
Comments please (if this deserves any!).

Ethy