C_interface_module page at Fortran Wiki

1

At the Fortran Wiki there is a c_interface_module page stating that

Gfortran has a bug that prevents using aliases via “USE, ONLY” as done here

That page was last updated on January 18, 2012. I am able to compile the code shown with gfortran 13.3.0 and also a later version, so has the bug been fixed? If so, what was the earliest version of gfortran that fixed it? I have not used C interoperability much – could someone review this page and edit it as needed?

2

I can do that - I have used and use the C interfacing extensively ;), though this particular module is a new one to me.

3

I came across that module not so long ago while looking for a memcpy interface. It’s quite useful to have such module since I always endup rewriting the same interfaces to memcpy, fputs, fgets, abort, etc., over and over again
@Arjen, while you are at it, you could maybe mention that it does not compile with lfortran yet.
Last time I checked, lfortran was missing some constants in it’s iso_c_binding module like C_INTPTR_T or the C_INT_FAST.
It’s probably not to much of an effort to make this module compilable with all (?) compilers at the expense of some macros. I did not try though.

4

Re rewriting: very recognisable :slight_smile:

You have access to lfortran? (I have not tried it myself) Definitely good to have an overview of compilers where such a thing works or not.

1 Like
5

I do. The installation with conda works very smoothly (even on Windows :sweat_smile:).

6

I think this module or similar, would be a perfect fit in stdlib!

1 Like
7

I tried compiling the module as is with the following compilers and versions:

  • Linux: gfortran 8.5.0, 12.2.0, 13.2.0
  • Windows: gfortran 14.1.0, ifx 2025.0.0

All of them accepted the code. With extra checks on (–warn-all and -check:all) I got two warnings:

c_interface.f90:419:20:

  419 |         forall (i=1:strlen)
      |                    1
Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]

and:

c_interface.f90(332): warning #6706: There is a mixture of specific functions and specific subroutines for one generic-spec.   [F_C_STRING_PTR]
  subroutine F_C_string_ptr(F_string, C_string, C_string_len)
-------------^

Nothing more. I have not checked against lfortran yet, but it seems safe to assume that most compilers will accept the code. Note that my tests do not yet include actually using the routines.

8

Okay, I installed lfortran version 0.45.0. After adding definitions for a large number of kinds, I finally stopped at:

semantic error: Type mismatch in argument at argument (1); passed `type(c_ptr)` to `c_char_ptr`.
   --> c_interface.f90:392:33
    |
392 |     character(len=C_strlen_safe(C_string)) :: F_string
    |                                 ^^^^^^^^

lfortran is the only compiler that makes a difference between c_char_ptr and c_ptr. Changing the type to c_char_ptr brougth up the next hurdle: the intrinsic function c_associated() is not defined.

I guess I should report this at the lfortran github site.

9

Here is the report: Issues regarding the ISO_C_BINDING module · Issue #6130 · lfortran/lfortran · GitHub, thanks for reporting it. We need to fix these issues.

10

Some of the procedures in that module are made obsolete by Fortran 2023, which now includes the intrinsics:

Other procedures could be amended to use these procedures (when available).

For unsigned integer types, the non-standard vendor extensions recently added to gfortran and flang with the -funsigned flag could be used:

Absolutely agree: Should stdlib have interfaces to C functions? · Issue #583 · fortran-lang/stdlib · GitHub

1 Like