# How to convince management to use ISO\_C\_BINDING?

**URL:** <https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041>\
**Category:** Uncategorized\
**Created:** [July 21, 2022, 2:28pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041 "2022-07-21T14:28:26Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![giraffe](https://avatars.discourse-cdn.com/v4/letter/g/f1d935/32.png) [@giraffe](https://fortran-lang.discourse.group/u/giraffe)\
**Post date:** [July 21, 2022, 2:28pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/1 "2022-07-21T14:28:26Z")

</div>

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,

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [July 21, 2022, 2:37pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/2 "2022-07-21T14:37:26Z")

</div>

> [@giraffe](#):
>
> Again, my program is currently working? Why should I switch to iso\_c\_binding?

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.

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [July 21, 2022, 3:53pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/4 "2022-07-21T15:53:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![leetaylor](https://avatars.discourse-cdn.com/v4/letter/l/3d9bf3/32.png) [@leetaylor](https://fortran-lang.discourse.group/u/leetaylor)\
**Post date:** [July 21, 2022, 4:34pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/5 "2022-07-21T16:34:17Z")

</div>

> [@giraffe](#):
>
> But, I’m using gfortran with the cc compiler. These two have been around for what seems like forever. If I continue to only use these two compilers will I have problems in the future with cross compatibility?

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.

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [July 21, 2022, 4:36pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/6 "2022-07-21T16:36:25Z")

</div>

Just my $0.02:

- The ISO\_C\_BINDING module provides standardised interfaces to C, i.e., you can rely on your mixed-language coupling to be working in future; instead of just hoping that the C/Fortran calling _conventions_ you take for granted will be valid in 20 years from now.
- You get the benefit of better error detection, as with ISO\_C\_BINDING interfaces the compiler is able to detect bugs that would show up at link stage otherwise, for example, type errors.
- Interfaces help to document the APIs you are calling because the bindings are implemented in Fortran itself. Consequently, your software becomes easier to understand and maintain.

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [July 21, 2022, 4:56pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/8 "2022-07-21T16:56:28Z")

</div>

Let’s have a look at the following example code in C:

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

```fortran
! bar.f90
program main
    external :: foo

    call foo(42)
end program main

```

Just building and running the example:

```auto
$ gcc -c foo.c
$ gfortran -o bar bar.f90 foo.o
$ ./bar
42

```

Now say, we introduce a bug and write:

```fortran
    call foo(42.0)

```

The output will become:

```auto
$ ./bar
1109917696

```

The solution is to declare an interface binding to `foo_()`:

```fortran
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:

```auto
$ 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:

```auto
$ 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:

```c
#include <stdio.h>

void foo(int i)
{
    printf("%d\n", i);
}

```

And the corresponding Fortran interface `c_foo()`:

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

---

<div class="post-metadata">

**Author:** ![plevold](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/plevold/32/754_2.png) [@plevold](https://fortran-lang.discourse.group/u/plevold)\
**Post date:** [July 21, 2022, 6:02pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/9 "2022-07-21T18:02:11Z")

</div>

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_binding` and/or the _gfortran name mangling scheme_

With options

1. I am familiar with both
2. I know the gfortran name mangling scheme
3. I am familiar with `iso_c_binding`
4. I’m not familiar with either

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

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [July 21, 2022, 6:39pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/10 "2022-07-21T18:39:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\
**Post date:** [July 21, 2022, 9:13pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/12 "2022-07-21T21:13:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\
**Post date:** [July 22, 2022, 2:47pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/13 "2022-07-22T14:47:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![milancurcic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/milancurcic/32/2_2.png) [@milancurcic](https://fortran-lang.discourse.group/u/milancurcic)\
**Post date:** [July 22, 2022, 3:37pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/15 "2022-07-22T15:37:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [July 22, 2022, 5:20pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/17 "2022-07-22T17:20:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\
**Post date:** [July 23, 2022, 8:38pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/20 "2022-07-23T20:38:40Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [July 24, 2022, 3:54pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/21 "2022-07-24T15:54:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [August 10, 2022, 7:14pm UTC](https://fortran-lang.discourse.group/t/how-to-convince-management-to-use-iso-c-binding/4041/23 "2022-08-10T19:14:02Z")

</div>

I’d be happy to work with you to develop and execute such a plan, but

- I haven’t seen your code, so I don’t have sufficient information to do it yet
- I don’t even know what it’s for, so I’m not sure how tricky/complex any of the logic may be
- I’d base it on plans for future feature improvements and bug fixes, which I don’t yet know about
- and I can’t do it for free

If you’d like to discuss more, I’d be happy to schedule a time to talk. Just let me know.
