Re: Bindat can exhaust memory when unpacking to vector

[Eli Zaretskii]

> X-Spam-Status: No, score=0.653 tagged_above=-9999 required=6
>       tests=[SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652] autolearn=disabled
> From: Petteri Hintsanen <petterih@iki.fi>
> Cc: emacs-devel@gnu.org
> Date: Mon, 23 Oct 2023 22:36:01 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> Sorry, I was careless with wording; obviously what I meant was "slowed
> down due to paging."  I did not wait for long, maybe a minute or so.
> This machine has ample memory, 16 GB RAM plus another 16 GB swap space.
> 
> > 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?
> 
> No, not really.  Now when I think about it, it is fairly obvious that
> the programmer should realize this when using such low level mechanism
> as Bindat.
> 
> >> 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?
> 
> I was thinking of some kind of note about validation, e.g.:
> 
>   Notice that unpacking data to a vector of length LEN will
>   unconditionally preallocate memory with at least LEN bytes.  If LEN is
>   calculated from the input, it is a good idea to validate its value
>   before unpacking.
> 
> But, again, users of Bindat can be expected to know that tainted data
> should be sanitized.  And what is described above is an implementation
> detail.  So it does not make much sense to mention this in the manual.

Stefan, any comments?