Three IO library related problems

[Robert Virding]

Sorry for not replying a little earlier.

matthias@REDACTED writes:
>#1
>
>In R7B-3:
>
>	18> io_lib:fread("~d.~d", "22").            
>	
>	=ERROR REPORT==== 2-Aug-2001::21:37:53 ===
>	ERROR: "Error in process <0.54.0> with exit value: 
>	{function_clause,[{io_lib_fread,fread,[\".~d\",[],2,[22]]},
>	{erl_eval,expr,3},{erl_eval,exprs,4},{shell,eval_loop,2}]}\n" 
>	** exited: {function_clause,[{io_lib_fread,fread,[".~d",[],2,[22]]},
>	                             {erl_eval,expr,3},
>	                             {erl_eval,exprs,4},
>	                             {shell,eval_loop,2}]} **
>
>I think it should return {more, ....}. The thought of patching
>io_lib_fread.erl without a test suite makes me feel weak. 'catch'
>is a halfway useful workaround.

No, this is perfectly correct.  io_lib:fread/2 takes a format string
and an input string and tries to extract ALL the specified fields.  It
is not re-entrant!

The function io_lib:fread/3 is the re-entrant call where the first
argument is the continuation.  The initial continuation must be [].
It will return {more,Cont} as you wished.

>#2
>
>On a related note, it'd be nice if the man page/web page for io_lib
>said that the {more, ....} tuple returned from fread/2 can be used as
>a continuation for fread/3. 

If the manual implies that io_lib:fread/2 is the initial re-entrant
call then it is wrong.

>#3
>
>Back in November there was a discussion about operations with binaries
>and io sometimes guzzling memory. Just writing
>
>  3> {bla, Bin}.
>
>on the shell prompt for a modest-sized binary would consume huge
>amounts of RAM. This was traced to a bug in io_lib_pretty and
>Robert Virding posted a fix to the mailing list. The fix isn't in
>R7B-3. Has this slipped between the cracks, or is it waiting for
>a volunteer to submit a proper diff?

This fix has been implemented in the new R8 which is coming sometime
during the autumn.

       Robert