[Octave-bug-tracker] [bug #65712] sort over InF dimension coredumps

[Arun Giridhar]

Follow-up Comment #16, bug #65712 (group octave):

See comment #12 for where the memory was being allocated (inside Array-base.cc
to resize the array to fit larger dimensions). I have a patch going through
tests now on both compilers.

===

OK testing done with both clang and gcc.

Since this is touching Array, I don't want to push it when I'm starting to
feel drowsy lest I break something big. But pls do test it.

Output for me:
On GCC, there's no memory allocation for the 1e9 case. It returns instantly.

octave:1> for i = 1:100, sort (magic(3), inf); end
octave:2> for i = 1:100, sort (magic(3), 1e9); end
octave:3>


On Clang, there's still no memory allocation but it gives its old complaint
about inf:

octave:10> for i = 1:100, sort (magic(3), 1e9); end
octave:11> for i = 1:100, sort (magic(3), inf); end
error: sort: DIM must be a positive scalar integer


Patch:

--- a/liboctave/array/Array-base.cc     Tue May 07 20:56:04 2024 -0400
+++ b/liboctave/array/Array-base.cc     Tue May 07 22:32:23 2024 -0400
@@ -1814,7 +1814,19 @@ Array<T, Alloc>::sort (int dim, sortmode
     return m;
 
   if (dim >= dv.ndims ())
-    dv.resize (dim+1, 1);
+    {
+      // The dimension to sort along exceeds the array's dimensions.
+      // ==> array is already trivially sorted in such higher dimensions.
+      // ==> copy and return.
+
+      T *v = m.rwdata ();
+      const T *ov = data ();
+
+      for (octave_idx_type i = 0; i < m.numel (); i++)
+        v[i] = ov[i];
+
+      return m;
+    }
 
   octave_idx_type ns = dv(dim);
   octave_idx_type iter = dv.numel () / ns;


Note: This specific patch does not touch data.cc.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65712>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/