Re: Bindat can exhaust memory when unpacking to vector

[Eli Zaretskii]

> From: Petteri Hintsanen <petterih@iki.fi>
> Date: Sun, 22 Oct 2023 22:36:36 +0300
> 
> It appears that bindat-unpack can exhaust memory when it unpacks to a
> vector.  Consider the following Bindat type expression:
> 
>   (require 'bindat)
>   (defconst foo-bindat-spec
>     (bindat-type
>      (length uint 32)
>      (data vec length)))
> 
> If you then, for example, eval this
> 
>   (bindat-unpack foo-bindat-spec [255 255 255 255 0 1 2 3 4 5])
> 
> it will result in (make-vector 4294967295 0), which makes Emacs hang.

Hang or just slow down tremendously due to paging?  How much time did
you wait before deciding that Emacs hung?  And how much memory do you
have on that machine?

The above call to make-vector is supposed to signal a memory-full
error if the number of elements is more than the system can support,
but it cannot be smart enough to consider the amount of available VM.

> Now it can be argued whether this is a problem or not.

Can you argue why this should be considered a problem for Emacs to
solve, and not a cockpit error on the part of the Lisp program that
makes such calls?

> Nonetheless, I think it would be prudent to mention this potential
> pitfall in the Emacs Lisp manual so that users become aware of it.
> I can write a texinfo patch if you agree.

What would we say? that unpacking vectors larger than available memory
would cause Emacs to run out of memory?

> [Side note: vec seems to be the only bindat type that suffers from this.
> str (string) is another type that has a varying length, but it is
> unpacked by `substring' which will implicitly guard against nonsensical
> lengths.]

See above: make-vector is also protected.