print-length-limit

[Jim Ursetto]

I'd appreciate clarification as to whether this is a bug or acceptable.

Basically in ##sys#print, although outchr and outstr both respect the print limit, only outchr can actually exit. Much output is built from multiple calls to outstr so you can get very odd results. Furthermore outstr does not truncate anything under 3 chars so random parts of the output may show up.

Note that if you change outstr to exit when the limit is exceeded, it may not print the final ... depending on the last chunk length. In fact, not truncating when len <= 3 is only appropriate if we're done printing the whole object, which we cannot currently detect.

Below find some examples.

Example 1:

#;1> (current-output-port)
#<output port "(stdout)">
#;3> (##sys#with-print-length-limit 5 (lambda () (print (current-output-port))))
#<out......">

Explanation 1:

#<output port \"        -> #<out...
(stdout)                -> ...
">                      -> ">          (not truncated by outstr, len <= 3)

Example 2:

#;5> (use srfi-4)
#;7> (make-u8vector 5 255)
#u8(255 255 255 255 255)
#;8> (##sys#with-print-length-limit 5 (lambda () (print (make-u8vector 100 255))))
#u8(255...

Explanation 2:

#u8(        -> #u8(
255         -> 255       (exceeds print limit, but length < 3)
<space>     -> ...        (outchr truncates space to ... and exits)

Example 3:

#;9> (##sys#with-print-length-limit 5 (lambda ()
      (print (u8vector->blob (make-u8vector 20 255)))))
#${ffffffffffffffffffffffffffffffffffffffff...

Explanation 3:

The bytes are all printed with outstr (which does not truncate them or exit) and there is no outchr to exit. The entire bytevector is printed, and the final } is truncated to "..." by outchr (!)

Example 4:

#;10> (##sys#with-print-length-limit 5 (lambda ()
        (print (u8vector->blob (make-u8vector 20 0)))))
#${00...

Explanation 4:

Bytes are printed with outstr, but leading zeros are printed with outchr, which detects the limit and bails.

[sjamaan]

This is old enough (almost two years), we should take a look at it

[sjamaan]

Old enough, but nobody seems to care, and fixing it is nontrivial. Moving back to "someday"

[sjamaan]

This has been addressed for the most part by c6791b7b6c2e4cccc6c15ab646b304eff2209a22 / 938b33f44d0bc06131e215fd6a70712501b1af53

[felix winkelmann]

Ok, I close this now. Please reopen, if desired.