Yes, I'd like to do it.

Ok, I see what you mean. In the case of UniformOutput==true, current code (in stable) for cellfun only copies a function output if the ouput is defined. If it's undefined, it doesn't do the assignment. That's why you don't get the error.

This is done by the block of code starting on line 581 of cellfun.cc:

                  for (int j = 0; j < num_to_copy; j++)
                    {
                      if (tmp(j).is_defined ())
                        {
                          octave_value val = tmp(j);

                          if (val.numel () != 1)
                            error ("cellfun: all values must be scalars when UniformOutput = true");

                          retv[j] = val.resize (fdims);
                        }
                    }

and also at a similar block starting at line 596.

In the case of non-uniform output, Octave assigns the outputs in lines 663-664:

              for (int j = 0; j < num_to_copy; j++)
                results[j](count) = tmp(j);

which will assign the value, even if undefined, to a cell element. I guess the assignment operation does not check if the value being assinged is defined. I don't know if it should, or if we should take care not to assign undefined elements.

comment #7:

> It would be useful to me to better understand why the call to f within cellfun fails to generate the error that occurs when it's called alone, and whether something is being missed there that should be addressed.

When function f is called alone, the error is generated by the instruction where f is called. E.g. if we have a multi-assignment:
[a,b]=f(x)
the error happens when copying the function output to the lvalues a, b. This is in pt-assign.cc (tree_multi_assignment::evaluate_n), line 291:

                      octave_value tmp = rhs_val(k);

                      if (tmp.is_undefined ())
                        error ("element number %" OCTAVE_IDX_TYPE_FORMAT
                               " undefined in return list", k+1);

If the instruction is a simple assignment, the error is generated in pt-assign.cc (tree_simple_assignment::evaluate), line 103:

          if (rhs_val.is_undefined ())
            error ("value on right hand side of assignment is undefined");

So, this is done case by case, depending on the instruction. That's why we have to consider that also in cellfun and arrayfun.

There's also another case solved by the patch. It's the following:

octave:> function [r]=f(x); if(x>0) r=x ;end; end
octave:> a=f(3)
      a = 3
octave:> a=f(-3)
error: value on right hand side of assignment is undefined
octave:> % everything's fine up to now
octave:> a=cellfun(@f,{1,-2,3},"uniformoutput",false)
      a =
      {
        [1,1] = 1
        [1,2] =

error: octave_base_value::print (): wrong type argument '<unknown type>'

and you end up with a cell array (a) with an undefined element.

a simple check of inserting an error() line into f shows that cellfun does properly stop for errors in the function.

also, arrayfun shows the same behavior as cellfun.  updating title and added another BIST as
https://hg.savannah.gnu.org/hgweb/octave/rev/f901d8fd3091

i haven't looked through cellfun before, but there does appear to be an attempt to catch a mismatch in defined number of return variables. Starting with this block at Line 558:

          const octave_value_list tmp
            = get_output_list (interp, count, nargout, inputlist, fcn,
                               error_handler);
          int tmp_numel = tmp.length ();
          if (count == 0)
            expected_nargout = tmp_numel;
          else if (tmp_numel != expected_nargout)
            error ("cellfun: function returned unexpected number of values");

          if (nargout > 0 && tmp_numel < nargout)
            error ("cellfun: function returned fewer than nargout values");

So this check passes because f is defined with 2 outputs, which matches the cellfun call for 2 outputs.

Why the first actual call to f doesnt trigger the error is the question then.

In current stable and default branches, cellfun incorrectly assigns a value of zero for values not returned by the called function, when the function returns fewer outputs than declared.

octave:> ver octave
----------------------------------------------------------------------
GNU Octave Version: 9.3.1 (hg id: 81462b707b37)
GNU Octave License: GNU General Public License
Operating System: Linux 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec  5 13:09:44 UTC 2024 x86_64
----------------------------------------------------------------------
octave:> function [a,b]=f(x);a=x;end
octave:> s = struct ("a", 1, "b", 4);
octave:> [a,b]=cellfun(@f,{1,4})
a =
   1   4
b =
   0   0

Instead, I would expect an error, like the one you get when calling the function directly:

octave:> [a,b]=f(1)
a = 1
error: element number 2 undefined in return list