bugGNU Octave - Bugs: bug #67217, "cellfun: This code should be...

 
 

bug #67217: "cellfun: This code should be unreachable" during "demo copyobj 2"

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Sat 14 Jun 2025 12:10:23 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Release: 
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 21 Jun 2025 07:29:52 PM UTC, comment #9: 

There was an error in the second patch, sorry. Here are the two patches again (the first one doesn't change).

(file #57312, file #57313)

Fernando <tutissanalio>
Sat 21 Jun 2025 07:08:12 PM UTC, comment #8: 

Here are the changes splitted in two patches.

(file #57310, file #57311)

Fernando <tutissanalio>
Wed 18 Jun 2025 12:00:26 PM UTC, comment #7: 

I haven't tested the changes yet. But they look good to me, too.

Could you please split the changes into two patches? One that avoids the warning from comment #0 by using a consistent output type for "valcomp" in struct2hdl.m. And another one that throws an error in "cellfun".

Could you please also add a second argument for the function "fail" in the new test that can be used as a regular expression to match the expected error message?

Since this will be a change in behavior of "cellfun", should we also add a note about this in the NEWS file?

Markus Mützel <mmuetzel>
Group administrator
Sun 15 Jun 2025 03:16:34 PM UTC, comment #6: 

I resend the fix with a commit message. For testing, I use a simplified version of the code from comment #3:


fail ("cellfun (@(x) x, {5, true})");




(file #57294)

Fernando <tutissanalio>
Sat 14 Jun 2025 04:44:56 PM UTC, comment #5: 

This looks good to me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 14 Jun 2025 04:27:35 PM UTC, comment #4: 

A possible fix.

(file #57292)

Fernando <tutissanalio>
Sat 14 Jun 2025 02:22:28 PM UTC, comment #3: 

I just tried the following in Octave and in Matlab (R2024b):


function y=valcomp(x)
  if x<10
    y=0;
  else
    y=false;
  end
end

y=cellfun(@valcomp,{5,15})


In octave, it gives the same warning as in the OP, but it does not give an error. In Matlab, it throws an error:


Error using cellfun
Mismatch in type of outputs, at index 2, output 1 (double versus logical).
Set 'UniformOutput' to false.
+verbatim-

Maybe it's better for Octave to throw an error too, so that conversion is not necessary unless you set 'UniformOutput' to false.

Fernando <tutissanalio>
Sat 14 Jun 2025 12:28:07 PM UTC, comment #2: 

The problem is that the function applied to each element of the cell array does not always return a value of the same type. In some cases it returns a double (zero) and in some cases it returns a logical value.

In particular, it's the function

function out = valcomp (x, hdls)

  if (isfloat (x) && isscalar (x))
    out = any (x == hdls);
  else
    out = 0;
  endif

endfunction


defined in file struct2hdl.m.

I think cellfun should be modified to take this into account and convert the value without warning.

Fernando <tutissanalio>
Sat 14 Jun 2025 03:21:10 AM UTC, comment #1: 

I am not quite understand the code, but graphics properties are highly heterogeneous (strings and numbers) so, of course "fast_elem_insert" in cellfun would fail and it will go to "assign".

So the code works, but the warning seems bogus.
Also it seems like we are doing the job twice -- first trying "fast_elem_insert" and after it fails through "assign", Could we somehow skip the "fast..." sooner?


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 14 Jun 2025 12:10:23 AM UTC, original submission:  

Running "demo copyobj 2" in recent dev snapshot I see a lot of identical warnings:

warning: cellfun: This code should be unreachable.  Please report to bugs.octave.org
warning: called from
    struct2hdl>setprops at line 707 column 7
    struct2hdl at line 231 column 3
    struct2hdl at line 225 column 8
    copyobj at line 96 column 7
    __demo__ at line 25 column 2
    demo at line 154 column 7


This is something relatively new. Definitely not a problem with 10.2.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57312:  bug67217-1.cset added by tutissanalio (729B - application/octet-stream)
file #57313:  bug67217-2.cset added by tutissanalio (2KiB - application/octet-stream)
file #57310:  bug67217-1.cset added by tutissanalio (729B - application/octet-stream)
file #57311:  bug67217-2.cset added by tutissanalio (2KiB - application/octet-stream)
file #57294:  bug67217.cset added by tutissanalio (3KiB - application/octet-stream)
file #57292:  bug67217.diff added by tutissanalio (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by tutissanalio (Posted a comment)
  • -email is unavailable- added by dasergatskov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-21 tutissanalio Attached File- Added bug67217-1.cset, #57312
        Attached File- Added bug67217-2.cset, #57313
    2025-06-21 tutissanalio Attached File- Added bug67217-1.cset, #57310
        Attached File- Added bug67217-2.cset, #57311
    2025-06-18 mmuetzel StatusNone In Progress
    2025-06-15 tutissanalio Attached File- Added bug67217.cset, #57294
    2025-06-14 tutissanalio Attached File- Added bug67217.diff, #57292

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code