Re: Implications of indexing changes for code that calls Fortran

[John W. Eaton]

On 01/02/2017 06:04 PM, Nicholas Jankowski wrote:
> On Jan 2, 2017 12:03 PM, "John W. Eaton" <address@hidden
> <mailto:address@hidden>> wrote:
> > With the recent changes for octave_idx_type, some changes will be
> needed for most code that calls Fortran.  I've already made these
> changes for Octave itself, but Octave Forge code that passes integers to
> Fortran code is currently broken unless Octave is built with
> --disable-64.  Most such code assumes that octave_idx_type is the same
> size as a Fortran INTEGER but that is no longer always the case.
> Instead, octave_f77_integer_type (AKA F77_INT) is now the same size as a
> Fortran INTEGER and it may not always be the same size as octave_idx_type.
>
> Will these be hard fails (code halting error) or soft fails (incorrect
> answers that may or may not be obvious, and could be an ongoing
> reliability concern)?  I would hope the former (overflow errors), but
> are there possible cases of the latter? Is finding problem areas just a
> matter of grep'ing each package source for a keyword?

Unfortunately, Octave could crash with a segfault or you could just get 
wrong answers.

But that was already true of some Octave Forge code that inconsistently 
used "int" or "octave_idx_type" in prototypes for Fortran subroutines, 
at least if you tried to build with --enable-64.

These are declarations that we are making up to satisfy the C++ 
compiler, so they need to match the actual compiled Fortran code.

If the declarations are wrong, then the code can compile without 
warnings but then fail at run time.

Finding the places where this can happen is mostly a matter of looking 
for F77_FUNC or F77_XFCN and fixing the declarations of integers that 
are passed to the Fortran subroutines.  I've already done most of the 
Octave Forge code that I know about.  I'm not exactly sure yet how to 
submit the changes as I may not have a valid Source Forge login now.

jwe