[Octave-bug-tracker] [bug #40739] Attempt to allocate (size_t)-1 bytes when trying to length-INT_MAX create sparse vector

[Philipp Kutin]

Follow-up Comment #4, bug #40739 (project octave):

Gotta take a step back here, my initial report was posted a bit in a hurry.
The reason I sounded so alert was because I had a wrong mental model of sparse
matrices. I though that they were implemented using basically a list (as an
abstract, not implementation data type) to hold pairs of [column, row]
indices. But it seems the structure is that you have one array of length
#columns, and that one carries arrays of sparse-data indices, indexing
SparseRep.d[].

So, rows/colums aren't "symmetrical" as I have thought and the 2^31-1 case is
a bit cornerly: creating very long row vectors is conceptually fine, but
probably isn't that useful anyway.
(For example, issuing "s=sparse(1,2^30,123)" creates such a "sparse vector",
but allocates 4 GiB and takes a while to run (well, on the sanitized build,
which doesn't say much).

So corner cases at the limits of the allocation maximum indices are one thing,
but now, it's the earlier second comment
(https://savannah.gnu.org/bugs/?40739#comment2) that I consider more severe:
after all, that one means you silently get wrong indices and Octave doesn't
tell you. Should a new bug be opened for that one?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40739>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/