seeing this bug report mentioned in bug #57867, is mike's suggestion still compatible and worth pushing?

The warning comes from the following backtrace

#0  octave_char_matrix_str::string_value[abi:cxx11](bool) const (this=<optimized out>) at ../libinterp/octave-value/ov-str-mat.cc:238
#1  0x00007fe5b75c66bf in octave_char_matrix_str::short_disp (this=<optimized out>, os=...) at ../libinterp/octave-value/ov-str-mat.cc:274
#2  0x00007fe5b7b4f25b in octave_value::short_disp (this=0x7fe57cfed9b0, os=...) at ../libinterp/octave-value/ov.h:1228
#3  symbol_table::do_workspace_info[abi:cxx11]() const (this=0x7fe56019de80) at ../libinterp/corefcn/symtab.cc:1507
#4  0x00007fe5b7abfbd9 in symbol_table::workspace_info[abi:cxx11](int) (scope=1) at ../libinterp/corefcn/symtab.h:2095
#5  octave_link::set_workspace () at ../libinterp/corefcn/octave-link.cc:71

I am now using this change

diff --git a/libinterp/octave-value/ov-str-mat.cc b/libinterp/octave-value/ov-str-mat.cc
--- a/libinterp/octave-value/ov-str-mat.cc
+++ b/libinterp/octave-value/ov-str-mat.cc
@@ -234,6 +234,9 @@ octave_char_matrix_str::string_value (bo

   charMatrix chm (matrix);

+  if (chm.rows () > 1)
+    warning ("evaluating a character matrix as a string, only the first row is used");
+
   // FIXME: Is this correct?
   return chm.row_as_string (0);
 }
@@ -268,7 +271,8 @@ octave_char_matrix_str::short_disp (std:
 {
   if (matrix.ndims () == 2 && numel () > 0)
     {
-      std::string tmp = string_value ();
+      charMatrix chm (matrix);
+      std::string tmp = chm.row_as_string (0);

       // FIXME: should this be configurable?
       size_t max_len = 100;

and can now work with the GUI and run the full test suite in the GUI with no warnings.

Needs some polish and a warning ID, but I think this is a good first start to draw a line.

As a start, I agree with Colin because it at least doesn't silently discard data.  Longer term, I think we should identify those functions that are different from Matlab and consider individually whether they should be fixed for compatibility.

Thanks for the testing Ceral.

Philip ­- it could be argued that Octave behaves slightly worse here, because it is silently throwing away data. At least with the few examples I've shown here, Matlab either gives the entire array (yes, it is flattened in column major order, but it's complete), or throws an error saying that the argument must be a vector.

I would propose that Octave could do one of three things to make this better

1. Always return the entire array, squeezed into a vector following the normal column-major ordering.

2. Issue a warning while doing what it does today.

3. Throw an error when code tries to extract a string_value from an argument that has more than 1 non-singleton dimension.

Any of these changes can be made in just one place, in the octave_char_matrix_str::string_value method, and affect any function that tries to get a simple string from one of its arguments.

Matlab:

% added spaces to make strings the same length

>> s = [' this '; ' is a '; ' char '; 'matrix']

s =

 this
 is a
 char
matrix

>> sprintf (s)

ans =

   mticahshti arsari   x
 

>> sprintf ('%s', s)

ans =

   mticahshti arsari   x

>> error (s)

   mticahshti arsari   x
 

>>  help (s)

Warning: The following error was caught while executing 'helpUtils.helpProcess' class destructor:
Input must be a row vector of characters.

> In help (line 45)
>> struct (s, 0)

Error using struct
Field name must be a string vector.
 

>> system (s);

Error using system
Argument must contain a string.
 

>> strrep (s, 'a', 'b')

Error using strrep
Input strings must have one row.

Octave has many functions that operate on a char array with the concept of a "string", even though char arrays may be two- or higher-dimensional. Octave currently silently truncates char arrays when given to some functions that are expecting a string. Other functions flatten the char array into a vector (in column-major order). Some motivating examples:

>> s = ["this"; "is a"; "char"; "matrix"]
s =

this
is a
char
matrix

>> sprintf (s)
ans = this
>> sprintf ("%s", s)
ans = ticmhshai atsarr   i   x
>> error (s)
error: this
>> help (s)
error: help: 'ticmhshai atsarr   i   x' not found
>> struct (s, 0)
ans =

  scalar structure containing the fields:

    this   = 0

>> system (s);
sh: 1: this: not found
>> strrep (s, 'a', 'b')
ans = ticmhshbi btsbrr   i   x

The guilty function is octave_value::string_value. The code is labeled with a FIXME where it deliberately pulls out the first row of a 2-dimensional char array, so that seems like a prime candidate for discussion and resolution.

The list of functions affected is probably very long, but maybe we can gather together a short list and get a Matlab compatibility check as a starting point.