[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Olaf Till
Subject: Re: fortran_vec() vs data() - very first element is lost
Date: Mon, 24 Oct 2016 21:52:31 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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 
> > 
> >   
> >
> > 
> > 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 = ();
> 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.


public key id EAFE0591, e.g. on x-hkp://

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]