Re: fortran_vec() vs data() - very first element is lost

[Olaf Till]

On Mon, Oct 24, 2016 at 08:59:30AM -0700, Mike Miller wrote:
> On Mon, Oct 24, 2016 at 16:07:18 +0200, Patrick Boettcher wrote:
> > Hi list,
> > 
> > I'm still working in an .oct-file to get in and out complex and
> > double matrices.
> > 
> > I noticed something strange which makes me wonder whether I really got
> > it correctly:
> > 
> > I read here 
> > 
> >   
> > https://www.gnu.org/software/octave/doc/v4.0.1/Matrices-and-Arrays-in-Oct_002dFiles.html
> > 
> > that I should use the method fortran_vec() to get to the raw-buffer.
> > 
> > It seems I'm using it correctly to fill data into a matrix returned by
> > my oct-function. However, when using this method to access the data of
> > a matrix given to my function as an argument the very first element
> > contains garbage:
> 
> You may have found a bug with this example. I get the same bad result as
> you, but other small variations on this theme give the correct values.
> 
> Try
> 
>   auto matrix = args(0).complex_matrix_value ();
>   auto fdata = matrix.fortran_vec ();
>   auto data = matrix.data ();
> 
> or
> 
>   octave_stdout << args(0).complex_matrix_value ().fortran_vec ()[0];
> 
> Both of these give me the correct value in the zeroth index.
> 
> If you continue to get the wrong value, please report on the bug tracker
> (and investigate a little deeper or provide a patch if you can).
> 
> > When injecting data into octave I'm using fortran_vec() to get access
> > to the raw-buffer. Displaying the matrix in octave shows the first
> > element to be correctly set.
> 
> Yes, this is the right way to write copy external data into a matrix.

Looking into Octave-4.0, fortran_vec() differs from data() in having
two versions, one returning a const pointer, the other a non-const
pointer. I've searched a bit but could not find a rule what type is
substituted for 'auto' in this case -- the const on or the non-const
one. Could this possibly cause undefined behaviour of the compiler?
Does anyone know this?

data() and both fortran_vec() versions should access the same 'T*
slice_data;' pointer, even if the non-const fortran_vec() does a
'make_unique()' before. Considering this, and the above examples, the
issue 'smells' like undefined behaviour ... but I don't know ...

My 2 cents.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature