Three IO library related problems

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Three IO library related problems

Matthias Lang-2

#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.

----
#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.

--------------------
#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?

Robert's post:

   http://www.erlang.org/ml-archive/erlang-questions/200011/msg00112.html

Matthias


Reply | Threaded
Open this post in threaded view
|

Three IO library related problems

Robert Virding-4
Sorry for not replying a little earlier.

matthias 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


Reply | Threaded
Open this post in threaded view
|

Three IO library related problems

Matthias Lang-2

Matthias wrote
 > >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, ....}.

Robert wrote
 > 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!

If it's not intended to be re-entrant, why does fread/2 return {more, ...}
in some cases? Consider these two cases:

  io_lib:fread("~d.~d", "22")        crashes the process (function_clause)
  io_lib:fread("~d~d", "22")         returns {more,"~d",2,[22]}

If this is perfectly correct, then (a) how can I guess whether the
fread/2 is going to crash or return {more, ...} for a particular input
which only satisfies part of the format string and (b) why is it
crashing with function_clause as a reason instead of badarg?

 > >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.

When io_lib:fread/2 returns {more, ...}, it's returning something
which looks like a continuation for io_lib:fread/3, but isn't. With
some re-shuffling and wrapping it can be (ab)used as a "clayton's
continuation" for fread/2. My mistaken inference.

Matthias


Reply | Threaded
Open this post in threaded view
|

Three IO library related problems

Robert Virding-4
matthias writes:

>
>Robert wrote
> > 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!
>
>If it's not intended to be re-entrant, why does fread/2 return {more, ...}
>in some cases? Consider these two cases:
>
>  io_lib:fread("~d.~d", "22")        crashes the process (function_clause)
>  io_lib:fread("~d~d", "22")         returns {more,"~d",2,[22]}
>
>If this is perfectly correct, then (a) how can I guess whether the
>fread/2 is going to crash or return {more, ...} for a particular input
>which only satisfies part of the format string and (b) why is it
>crashing with function_clause as a reason instead of badarg?

This is definitely a bug and I will fix it.  If I can still remember
how the code works. :-)  As you have already noticed the format of the
{more,...} tuple is different:

5> io_lib:fread("~d~d", "22").    
{more,"~d",2,[22]}
6> io_lib:fread([],"~d~d", "22").
{more,{"~d~d","22",0,[]}}

Which "proves" that there is a bug.  Actually it seems quite buggy.
Sigh!

        Robert