If I have my C/Fortran program working pretty well today!. What should I say to my manager to convince them to switch to using the iso_c_binding package?
I only have a few minutes to convince them.
Again, my program is currently working? Why should I switch to iso_c_binding?
Thank you,
iso_c_binding is part of the standard since Fortran 2003. Using it will help your program to continue to work in the future, with other or new compilers: it will be more robust.
Probably not, but I think it depends how long you expect your program to be used. If it’s 3 years it’s OK. But 10 years or 20 years or more is different. Maybe for some unknown reason you will have to use other compilers. No one knows what will happen in more than one decade.
Within the past few versions, the type of the hidden argument used to pass character string lengths changed from int to size_t. So even using the same compiler you may run into issues in the future.
Just my $0.02:
Let’s have a look at the following example code in C:
/* foo.c */
#include <stdio.h>
void foo_(int *i)
{
printf("%d\n", *i);
}
Using C/Fortran calling conventions, we can invoke routine foo_() from Fortran without an ISO_C_BINDING interface:
! bar.f90
program main
external :: foo
call foo(42)
end program main
Just building and running the example:
$ gcc -c foo.c
$ gfortran -o bar bar.f90 foo.o
$ ./bar
42
Now say, we introduce a bug and write:
call foo(42.0)
The output will become:
$ ./bar
1109917696
The solution is to declare an interface binding to foo_():
program main
use, intrinsic :: iso_c_binding
interface
subroutine c_foo(i) bind(c, name='foo_')
import :: c_int
implicit none
integer(kind=c_int) :: i
end subroutine c_foo
end interface
call c_foo(42)
end program main
The output is the same:
$ gcc -c foo.c
$ gfortran -o bar bar.f90 foo.o
$ ./bar
42
But in contrast, the introduced bug (42.0) will be detected by the compiler:
$ gfortran -o bar bar.f90 foo.o
bar.f90:12:20:
12 | call c_foo(42.0)
| 1
Error: Type mismatch in argument 'i' at (1); passed REAL(4) to INTEGER(4)
Furthermore, with ISO_C_BINDING interfaces we can pass procedure arguments by value (otherwise, only by reference [1]), and don’t need the trailing underscore in C procedure names. That means, the C code can become:
#include <stdio.h>
void foo(int i)
{
printf("%d\n", i);
}
And the corresponding Fortran interface c_foo():
interface
subroutine c_foo(i) bind(c, name='foo')
import :: c_int
implicit none
integer(kind=c_int), intent(in), value :: i
end subroutine c_foo
end interface
[1] If you don’t want to rely on compiler extensions.
If management cares about such details in the code you write then they’re micromanaging you. That won’t lead to any good for anyone. Instead you should care about convincing the other developers on your team. If you’re working solo they should set you up with another Fortran developer or group of Fortran developers in-house for discussing technical topics like this. If you’re the only active Fortran developer in the company they should hire more or trust you enough to make decisions like this on your own.
You could also make a simple poll in our discourse asking something like
Are you familiar with
iso_c_bindingand/or the gfortran name mangling scheme
With options
iso_c_bindingFor those who choose answer 3 or 4 your code will be easiest to understand if it’s using iso_c_binding. If that is a significant portion then future employees will probably be most comfortable getting into the code if it’s using iso_c_binding.
This is the kind of change that you do not need to make all at once. You can convert the routines one at a time, with whatever appropriate testing is required for each one. In a few days or a few weeks, it will all be converted with what seemed like minimal effort. Then once they are all coverted to interface blocks, which may be collected together in one place, you can make changes much easier in the C code itself (such as removing the trailing _, or using the normal C pass-by-value argument association). You change the C code, you change the interface block, recompile, and the whole shebang will work.
If you value support from forums such as this; being standard-conformant means you can get support from a much broader sector of the community, that you have not based your code on a single arbitrary implementation but upon an ISO standard supported by a variety of compilers that can provide support for GPUs, interactive and/or web interfaces that your current platform may not support and can port to other platforms and find future staff support that will not need to learn and maintain non-standard products, for starters. Other products that often assume code is standard-compliant (from debuggers to profilers to IDEs and features such as auto-completion will not be accessible or will provide less complete support in general for non-standard implementations Most business people are quite familiar with the values of standardization in everything from the shape and size of shipping containers to electronic transfers to commerce laws etc.etc. The value of standards dates back at least to the Industrial Revolution if not the Tower of Babel.
Assuming you are convinced yourself, would it be feasible to do it on your own (even in your spare time if not possible otherwise) and report back to management only when it’s done and you have concrete improvements to show?
I’m not recommending either way but merely wondering if it’s a possibility for you. Many employers allow and encourage employees to take initiative on mini-experiments on their own.
I understand, I didn’t know that was the situation. I wish you good luck with the rest of the project and the job search.
Yes, it is those interface blocks that really do all the work. Once those are set up, it is then straightforward to change compilers, operating systems, calling conventions, and so on.
I cannot answer that question for you. I can tell you that I have legacy code in a similar shape. I used conditional compilation to account for the various ways that fortran compilers needed to interface to the C compiler, some on the fortran side and some on the C side. The various possibilities include fortran compilers that generate external references in upper or lower case and with or without the trailing _ character. There might have been a few other quirks, but those four cases were the major ones. I work with dozens of other programmers, we all have different funding sources and so on, so it is not like we can all take a month and work together to convert everything at once. “If it ain’t broke, don’t fix it.” So instead we wait until something breaks, and then we go in and fix it with modern code options and replacements. That’s not ideal, but that is our practical path.
You do not need to put an interface block in every routine that references a given C procedure. You instead put the block in a module, and then USE that module. So in this way, the maintenance is simplified from that point on for that routine. You can then work one routine at a time as necessary.
Of course, you need to thoroughly test the changes as you make them. Don’t just settle for getting the code to compile, actually test the code and make sure that all of the changed code is actually executed.
From what I can tell, you’ve already run head first into the problem that occurs when you don’t use iso_c_binding. The argument to management is, the next time we want/need to change anything about the environment in which we use the code (compiler, OS, etc.), we risk having to spend a similar amount of time to what we just did (i.e. months) solving the exact same problems we just encountered.
If management knows for sure that this code will never be used again, then there is of course no reason to spend any effort improving its situation. If it will continue to be used, I can promise that the nature of software is that requirements change and changes to the software will be necessary. Neglecting to make improvements now is delaying short-term maintenance at a time when it could very well be budgeted for and scheduled and increasing long-term risk. It’s a short-sighted approach that may save money in the short-term, but could very well lead to a disaster later. As an analogy, most people would see the folly in neglecting to change the oil or rotate the tires on their car because it’s running fine now.
I’d be happy to work with you to develop and execute such a plan, but
If you’d like to discuss more, I’d be happy to schedule a time to talk. Just let me know.