numeric_to_ascii_base_ generates 8-digit octal integer strings that cv_oct_ cannot convert

[Gary Dixon]

MCR10101 changes to numeric_to_ascii_base_ added an algorithm for returning a result including an exponent to suppress trailing zeros immediately before the radix point. Unfortunately, analyze_multics uses cv_oct_ to convert strings back to fixed bin(35) numbers, and that interface cannot handle input strings that include an exponent. The current code converts strings with more than 5 consecutive 0 chars before the radix point to use an exponent. For example:

This problem is especially severe because Multics absolute address include 24-bits of data (8 octal digits). So an address of 1000000. is converted to 1e+6o as shown using the test program tcfps.

tcfps 8 1 11 (100000o 1000000o)

tcfps -------  8   in: "100000o"
           dump:  +00000000000000000000000000000000000000000000000000000032768. E0
 Sig          10  out:  32768
        base:  8  out:  100000o

tcfps -------  8   in: "1000000o"
           dump:  +00000000000000000000000000000000000000000000000000000262144. E0
 Sig          10  out:  262144
        base:  8  out:  1e+6o

[Gary Dixon]

This problem can be partially resolved very easily by increasing the number of consecutive zeros before the radix point that trigger use of exponential format: from "more than 5" to "more than 7". With that change, any Multics absolute address value is guaranteed to be expressible without getting an exponent in the numeric string.

A more complete resolution might require adding arguments to the numeric_to_ascii_base_ interface specifying whether the caller is willing to accept a result string expressed with exponents, or a result string including fractional characters (to the right of the radix point), or a result string including a radix indicator string, etc.

[Eric Swenson]

​https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10129_azm_2.4_v1.8.pdf

[Eric Swenson]

Fixed in MR12.8-1054.