bugGNU Octave - Bugs: bug #51754, MEX interface returns odd NULL...

 
 

bug #51754: MEX interface returns odd NULL objects

Submitter:  Rik <rik5>
Submitted:  Mon 14 Aug 2017 11:28:41 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 15 Aug 2017 05:05:20 PM UTC, comment #8: 

I made a few changes here (http://hg.savannah.gnu.org/hgweb/octave/rev/185f850aa543).  The issue was that we were asking people to experiment with using different numbers of input and output arguments and they could see how that was communicated to nlhs and nrhs.  However, if they did experiment with more than 0 outputs then the code would produce an error which isn't very user-friendly.  They might think they had not understood the example, or not coded it correctly.

I think this issue has been resolved so I'm going to close this report.

Rik <rik5>
Group administrator
Tue 15 Aug 2017 03:08:47 PM UTC, comment #7: 

I looked and I don't see anything to fix.  I don't see where we show any examples of calling functions with more outputs than they produce and expecting things to work.  Did I miss something?

If we want to document this behavior, then it seems like it belongs in more introductory material or in the description of how functions or [x,y,...] = foo () assignment statements work, not in the .oct and .mex file guide.

John W. Eaton <jwe>
Group administrator
Tue 15 Aug 2017 02:34:03 PM UTC, comment #6: 

OK, I can take a look at fixing those things.

John W. Eaton <jwe>
Group administrator
Tue 15 Aug 2017 02:11:40 PM UTC, comment #5: 

Seems reasonable to be Matlab-compatible in this regard as it is generally easier on the programmer if the interpreter stops as close to the location in the code where an error occurred.  Having an undefined value and propagating it through several m-files before something eventually fails is unfriendly.

Alas, it also creates some more work.  The documentation and code examples in Appendix A : External Code Interface now need to be updated as helloworld.cc, myhello.c, mex_demo.c all produce errors now when called with multiple outputs.

Rik <rik5>
Group administrator
Tue 15 Aug 2017 01:10:12 PM UTC, comment #4: 

I checked a set of changesets that should address this issue:

http://hg.savannah.gnu.org/hgweb/octave/rev/85488effc0ff
http://hg.savannah.gnu.org/hgweb/octave/rev/47c44b822d11
http://hg.savannah.gnu.org/hgweb/octave/rev/7662b441e2ea

The first should fix the problem with attempting to print undefined values returned from functions.  It also considerably simplifies returning values from functions, so I hope it improves performance, if only slightly.  It also changes the behavior of Octave: now outputs that are not initialized in a function are left undefined instead of being set to [].  And attempting to assign an undefined value returned from a function is an error.  So I fixed one place where that was a problem and also eliminated the now unused Octave::undefined-return-values warning ID.

John W. Eaton <jwe>
Group administrator
Tue 15 Aug 2017 12:27:17 AM UTC, comment #3: 

Yes, totally agree about the error not making sense.

Piotr Held <jsoh425>
Tue 15 Aug 2017 12:26:17 AM UTC, comment #2: 

Octave usually just issues a warning, rather than a full error for this situation.  Even if an error was to be printed, it should be something reasonable rather than something strange about wrong_type_argument.

I tried this, but unfortunately it didn't work.


diff -r adf580507691 libinterp/corefcn/mex.cc
--- a/libinterp/corefcn/mex.cc        Mon Aug 14 16:55:52 2017 -0700
+++ b/libinterp/corefcn/mex.cc        Mon Aug 14 17:23:13 2017 -0700
@@ -3196,8 +3196,13 @@ call_mex (octave_mex_function& mex_fcn,

   retval.resize (nargout);

+  int j = 0;
   for (int i = 0; i < nargout; i++)
-    retval(i) = mxArray::as_octave_value (argout[i]);
+    {
+      if (argout[i])
+        retval(j++) = mxArray::as_octave_value (argout[i]);
+    }
+  retval.resize (j);

   return retval;
 }


Rik <rik5>
Group administrator
Mon 14 Aug 2017 11:50:14 PM UTC, comment #1: 

I do see your point however, the Matlab output for this file is:


Hello, World!
I have 1 inputs and 3 outputs
One or more output arguments not assigned during call to "mex_demo".


So an error would make sense (if we want to Matlab compatible in this respect).

Piotr Held <jsoh425>
Mon 14 Aug 2017 11:28:41 PM UTC, original submission:  

Since this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/2e4033e1f28f) the MEX interface returns undefined objects rather than empty matrices ([]) for unused outputs.  It is Matlab compatible that these objects be undefined, however it causes problems back in Octave.

Example code is taken from mex_demo.c in the examples/code directory.


#include "mex.h"

void
mexFunction (int nlhs, mxArray *plhs[],
             int nrhs, const mxArray *prhs[])
{
  mexPrintf ("Hello, World!\n");

  mexPrintf ("I have %d inputs and %d outputs\n", nrhs, nlhs);

  mxArray *v = mxCreateDoubleMatrix (1, 1, mxREAL);
  double *data = mxGetPr (v);
  *data = 1.23456789;

  plhs[0] = v;
}


Compile and then run


octave:2> [a,b,c] = mex_demo (1)
Hello, World!
I have 1 inputs and 3 outputs
a =  1.2346
b =

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


It seems like Octave might need to prune the octave_value_list that is returned to only non-null values.


Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jsoh425 (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-15 rik5 StatusNone Fixed
        Open/ClosedOpen Closed
    2017-08-14 rik5 Carbon-Copy- Added jsoh425
        Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code