Portable declaration of REAL variables in mex gateway for Fortran

(The same question is asked here: https://stackoverflow.com/questions/57244555/portable-declaration-of-real-variables-in-mex-gateway-for-fortran)

I am writing a mex gateway for a piece of Fortran code.

In the Fortran code, for portability, the floating-point variables are declared as

REAL(kind(0.0D0)) :: x, y, etc

(BTW, I am aware that there are better ways to do it, as discussed at

https://stackoverflow.com/questions/3170239/fortran-integer4-vs-integer4-vs-integerkind-4,

https://stackoverflow.com/questions/10520819/what-does-real8-mean?noredirect=1&lq=1, and

https://software.intel.com/en-us/blogs/2017/03/27/doctor-fortran-in-it-takes-all-kinds )

However, it seems to me that mex supports only REAL*8 and REAL*4, the former being Double, the latter being Single. I got this impression from the following functions/subroutines:

mxIsDouble, mxIsSingle, mxCopyPtrToReal8, mxCopyReal8ToPtr, mxCopyPtrToReal4, mxCopyReal4ToPtr

My questions are as follows.

1. Is it true that mex supports only REAL*8 and REAL*4?
2. Are REAL*8 and/or REAL*4 supported on all platforms? If no, does this mean that MATLAB mex is intrinsically unportable?
3. What is the best way to specify the kind of floating-point variables in mex gateways for Fortran code?
4. Does it improve the portability of the mex gateway if I declare double-precision floating-point variables as

REAL(kind(0.0D0)) :: x, y, etc

or even

integer, parameter :: dp = selected_real_kind(15, 307)
real(kind=dp) :: x, y, etc

Or should I simply declare

REAL*8 :: x, y, etc 

Thank you very much!

The following code is an example. See the declaration of x, y, and xs.

#include "fintrf.h"
      subroutine mexFunction(nlhs, plhs, nrhs, prhs)
C     y = square (x) 
C     x: a floating point scalar
C     y: x^2

      implicit none

C     mexFunction arguments 
      integer, intent(in) :: nlhs, nrhs 
      mwPointer, intent(in) :: prhs(nrhs)
      mwPointer, intent(inout) :: plhs(nlhs)

C     function declarations:
      mwPointer, external :: mxCreateDoubleScalar, mxGetPr
      mwSize, external :: mxGetM, mxGetN
      integer*4, external :: mxIsDouble, mxIsSingle 

C     variables
      mwSize, parameter :: mwOne = 1
      integer, parameter :: dKind = kind(0.0D0) 
      integer, parameter :: sKind = kind(0.0) 
      real(kind=dKind) :: x, y ! Does this improve the portablity?
      real(kind=sKind) :: xs ! Does this improve the portablity?

C     validate number of arguments
      if (nrhs .ne. 1) then
         call mexErrMsgIdAndTxt ('mex:nInput', '1 input required.')
      endif
      if (nlhs .gt. 1) then
         call mexErrMsgIdAndTxt ('mex:nOutput', 'At most 1 output.')
      endif

C     validate input
      if (mxIsDouble(prhs(1)) .ne. 1 .and. mxIsSingle(prhs(1)) .ne. 1) 
      ! What if the input is a floating point number but neither Double nor Single? 
     + then 
          call mexErrMsgIdAndTxt ('mex:Input', 'Input a real number.')
      endif
      if (mxGetM(prhs(1)) .ne. 1 .or. mxGetN(prhs(1)) .ne. 1) then
          call mexErrMsgIdAndTxt ('mex:Input', 'Input a scalar.')
      endif

C     read input
      if (mxIsDouble(prhs(1)) .eq. 1) then
         call mxCopyPtrToReal8(mxGetPr(prhs(1)), x, mwOne) 
      else
         call mxCopyPtrToReal4(mxGetPr(prhs(1)), xs, mwOne)
         x = real(xs, dKind) 
         ! What if the input is a floating point number but neither REAL*8 nor REAL*4
      endif
      
C     do the calculation
      y = x**2

C     write output
      plhs(1) = mxCreateDoubleScalar(y)

      return
      end subroutine mexFunction

Answer 1

[James Tursa]

The REAL(kind(0.0D0)) vs REAL*8 discussion (and INTEGER*4 vs INTEGER etc) is a compiler issue, not a mex issue. As long as your compiler understands it, mex will be fine with it. For the systems you are working on, REAL(kind(0.0D0)) and REAL*8 are almost certainly different syntaxes for the same thing. Discussions about which syntax should be used are best left to another forum. MATLAB uses REAL*8 in its documentation, but you can use REAL(kind(0.0D0)) and be just fine.

[Zaikun Zhang]

Thank you, James, for the informative answer. I agree that the REAL(kind(0.0D0)) vs REAL*8 discussion is a comipler issue. The mex issue is why MATLAB insists on the nonstandard REAL*8/REAL*4/INTEGER*4, and, with such nonstandard features, how we could write mex gateways that both meet the Fortran standards and work correctly with all supported compilers/OS's.

Maybe the "right" thing to do is just write REAL*8/REAL*4/INTEGER*4 as in the MATLAB documents and forget about the Fortran standards?

Thank you very much!

[James Tursa]

You would almost certianly be OK to use REAL(kind(0.0D0)) instead of REAL*8, REAL(kind(0.0)) instead of REAL*4, etc. in your mex code and you would be just fine. Go ahead and use the standard syntaxes if you want to and the interfaces to the mex API routines should still work correctly. If you ever run into a problem doing this I would sure like to hear about it. The only thing to be careful of, as mentioned in your other post, is if there are compiler settings in play that force a certain syntax to be other than what if would be under default settings. That can certainly mess things up.

[Zaikun Zhang]

I agree. I will use REAL(kind(0.0D0)) instead of REAL*8, REAL(kind(0.0)) instead of REAL*4. For INTEGER*4, I will write SELECTED_INT_KIND(8), which works well (i.e, lead to 32bit INTEGER) with both -compatibleArrayDims and -largeArrayDims. I will surely come back to inform you if these settings cause problems. Many thanks again!