[R-pkg-devel] [Re] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

Pierre Lafaye de Micheaux |@|@ye @end|ng |rom un@w@edu@@u
Fri Dec 18 08:25:35 CET 2020


Dear Ivan,

Thank you for your comment. And also for the previous one.

I indeed made a mistake with JOBZ, RANGE and UPLO, now changed to:

    const char *CJOBZ = jobz[0];
    const char *CRANGE = range[0];
    const char *CUPLO = uplo[0];
...
    delete[] CJOBZ;
    delete[] CRANGE;
    delete[] CUPLO;

I did a bit of F77 programming almost 20 years ago when I did my Ph.D. thesis, but I never programmed in Fortran 2003. I remember having tried a few months back to use the iso_c_binding approach (before your previous email) with no success. I will give it a try to see if I can make it work.

Have a nice day.

Kind regards,
Pierre
________________________________
From: Ivan Krylov <krylov.r00t using gmail.com>
Sent: Friday, 18 December 2020 18:16
To: Pierre Lafaye de Micheaux <lafaye using unsw.edu.au>
Cc: Tomas Kalibera <tomas.kalibera using gmail.com>; Prof Brian Ripley <ripley using stats.ox.ac.uk>; R Package Devel <r-package-devel using r-project.org>
Subject: Re: [R-pkg-devel] [Re] warning: type of �zhpevx_� does not match original declaration [-Wlto-type-mismatch]

Dear Pierre L.,

I think that the zhpevxC wrapper, as written, may result in undefined
behaviour:

>    const char *JOBZ = jobz[0];

>    delete[] JOBZ;

>    delete[] Cap;

This could work okay, depending on how the rest of the package is
written, but in general, it is considered a bad idea for linear algebra
routines to deallocate memory they didn't allocate. ("Pointer
ownership is usually retained by the calling code.")

May I suggest once again the idea of writing a Fortran 2003 wrapper
zhpevxC instead of C++? Subroutines defined using iso_c_binding are
guaranteed to follow the C calling convention, and, this being Fortran,
call zhpevx(...) is guaranteed to match the Fortran calling convention,
bringing you the best of both worlds:

https://stat.ethz.ch/pipermail/r-package-devel/2020q3/005710.html

No need to allocate or deallocate memory or provide different
definitions depending on the availability of FC_LEN_T, just make sure
that both prototypes mean the same thing. By the way,
std::complex<double> is guaranteed to match the memory layout of C type
double _Complex and Fortran type complex(kind = c_double_complex) by
the respective standards.

--
Best regards,
Ivan

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list