Building upon my earlier post, if you have the following function in a module
use, intrinsic :: iso_c_binding, only: c_int
integer(c_int) function add_one(x)
integer(c_int), intent(in), value :: x
integer(c_int) :: add_one
add_one = x + 1
the output with x86-64 gfortran 11.3 will be named
__m_MOD_add_one, however with x86-64 ifort 2021.5 it will be named
If you add
bind(c) it will be called
add_one in both cases, just as the C caller would expect. You could interpret this as a friendship gesture towards C programmers who will be using the Fortran routine as a black-box, and they will not need to worry about name mangling, if they will ever need a different Fortran compiler.
From the snippets of code you (@giraffe) have shown before, it appears your project isn’t using modules, but only external subprograms. The Fortran compilers I could test on GodBolt all used the mangling convention of appending a single underscore in this case, i.e. the output would be named
In an earlier thread you wrote:
ISO_C_BINDING involves more code which can be considered clutter by some people, not me of course!
I do believe that people can be prejudiced to what they perceive to be unnecessary clutter if they only want the code to work on a specific operating system and aren’t planning for other contingencies.
You could certainly go down this route, but along the lines of @themos, the technical debt will come to bite those people at some point, just as they have been bitten now when porting from a 32- to a 64-bit operating system (albeit on a different issue of widths). Out of curiosity, in which language are you (or your company) planning to do the rewrite in?
Concerning unneccesary clutter, you can reduce it by packing your subroutines in a module, then you will need only a single
use, intrinsic :: iso_c_binding statement. If you are annoyed by the verbose parameter constants such as
c_int, use renaming upon import, i.e.
use, intrinsic :: iso_c_binding, only: dp => c_double, ip => c_int