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

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Fri Dec 18 09:14:36 CET 2020


On 12/18/20 8:25 AM, Pierre Lafaye de Micheaux wrote:
> 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;

Dear Pierre,


this unfortunately still does not look right. You are calling "delete[]" 
on something you have not allocated with "new". This code will not work 
(or if so, only by coincidence only sometimes, but crash other times or 
produce incorrect results) and you should be seeing a number of compiler 
warnings if not errors. "jobz" is a "char *" (unless something changed 
from you previous example), so jobz[0] is a "char", so not a pointer at all.


>
> 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.

That would be best, but I would certainly advise against doing runtime 
tricks (such as copying the memory, etc) to silence benign compiler 
warnings. The version I was looking at seemed ok to me, and a recent 
compiler would not emit warnings - perhaps you could just upgrade your 
OS?� If you just extended the use of the FC_ macros there to make that 
work also when the hidden character arguments were not used, that would 
be good enough for now I think. For the iso_c_binding, there is an 
example in Writing R Extensions (but does not include the complex type).


Best,

Tomas

>
> 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