[erlang-questions] zlib design flaw?

[Park, Sungjin]

Related with this problem, I tried attached simple patches to define
zlib:inflate/3.  The last parameter, MaxSize is handed over to the port
driver.  And changed the port driver to stop streaming at this point.

Patches compile good but at runtime, I get undefined function exception
even it's exported by zlib.erl

1> Data=<<"0123456789">>.
2> Compressed=zlib:compress(Data).
3> Z=zlib:open().
4> zlib:inflateInit(Z).
5> catch zlib:inflate(Z,Compressed,9).
{'EXIT',{undef,[{zlib,inflate,
                      [#Port<0.582>,

 <<120,156,51,48,52,50,54,49,53,51,183,0,0,8,241,1,213>>,
                       9],
                      []},
                {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]},
                {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,434}]},
                {shell,exprs,7,[{file,"shell.erl"},{line,676}]},
                {shell,eval_exprs,7,[{file,"shell.erl"},{line,631}]},
                {shell,eval_loop,3,[{file,"shell.erl"},{line,616}]}]}}
...

And also I get einval error (maybe from the port driver) when I call
zlib:inflate/2.

6> catch zlib:inflate(Z,Compressed).
{'EXIT',{einval,[{zlib,call,3,[]},
                 {zlib,inflate,2,[]},
                 {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,661}]},
                 {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,434}]},
                 {shell,exprs,7,[{file,"shell.erl"},{line,676}]},
                 {shell,eval_exprs,7,[{file,"shell.erl"},{line,631}]},
                 {shell,eval_loop,3,[{file,"shell.erl"},{line,616}]}]}}

I suspect that the port driver patch is applied but zlib.erl is not.
Is there any other place that I have to define zlib:inflate/3?  Or did I
make other mistake?


On Thu, Sep 25, 2014 at 1:11 PM, Richard A. O'Keefe <ok@REDACTED>
wrote:

>
> On 25/09/2014, at 5:46 AM, Tony Rogvall wrote:
> >
> > Thanks. Cool stuff :-)
> >
> > The following is also a fun version ( I am not the only one to blame for
> api design faults :-)
>
> [[billion laughs]]
>
> Wikimedia markup has the same problem.
>
> For that matter, templates make the C++ type language
> a Turing-complete (but seriously ugly) functional programming
> language, and the various features that have been added to
> the Haskell type system since 2010 make that a Turing-complete
> logic programming language, so you can write a fairly short
> C++ or Haskell program that takes as long to type-check as
> you please.
>
> The Erlang binary term representation is just on the safe side
> of this kind of attack.  The fact that backreferences can only
> be used to refer to *atoms* keeps it safe.
>
> I'm a little bit sad that this seems like a good reason not
> to make the binary representation "smarter".
>
> Oh heck.  The binary format I use to provide persistence for
> Smalltalk has precisely this kind of problem, but if I
> *didn't* allow backreferences to arbitrary objects I would not
> be able to handle cyclic object graphs.
>
> I console myself: UBF(A) is on the wrong side of the safety
> line.  The term you get by decoding n UBF(a) bytes will be
> O(n) in size, but it may take O(2**n) time to traverse it.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
Park, Sungjin
-------------------------------------------------------------------------------------------------------------------
Peculiar travel suggestions are dancing lessons from god.
  -- The Books of Bokonon
-------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140925/2060020b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib_drv.patch
Type: application/octet-stream
Size: 1954 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140925/2060020b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib_SUITE.patch
Type: application/octet-stream
Size: 651 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140925/2060020b/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib.patch
Type: application/octet-stream
Size: 1081 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140925/2060020b/attachment-0002.obj>