> On Mar 21, 2024, at 6:35 PM, Jed Brown <[email protected]> wrote: > > Barry Smith <[email protected]> writes: > >> In my limited understanding of the Fortran iso_c_binding, if we do not >> provide an equivalent Fortran stub (the user calls) that uses the >> iso_c_binding to call PETSc C code, then when the user calls PETSc C code >> directly via the iso_c_binding they have to pass iso_c_binding type >> arguments to the call. This I consider unacceptable. So my conclusion was >> there is the same number of stubs, just in a different language, so there is >> no reason to consider changing since we cannot "delete lots of stubs", but I >> could be wrong. > > I don't want users to deal with iso_c_binding manually. > > We already have the generated ftn-auto-interfaces/*.h90. The INTERFACE > keyword could be replaced with CONTAINS (making these definitions instead of > just interfaces), and then the bodies could use iso_c_binding to call the C > functions. That would reduce repetition and be the standards-compliant way to > do this.
Sure, the interface and the stub go in the same file instead of two files. This is slightly nicer but not significantly simpler, and alone, it is not reason enough to write an entire new stub generator. > What we do now with detecting the Fortran mangling scheme and calling > conventions "works" but doesn't conform to any standard and there's nothing > stopping Fortran implementations from creating yet another variant that we > have to deal with manually. From practical experience, calling C/Fortran using non-standards has only gotten easier over the last thirty-five years (fewer variants on how char* is handled); it has not gotten more complicated, so I submit the likelihood of "nothing stopping Fortran implementations from creating yet another variant that we have to deal with manually" is (though possible) rather unlikely. As far as I am concerned, much of iso_c_binding stuff just solved a problem that never really existed (except in some people's minds) since calling C/Fortran has always been easy, modulo knowing a tiny bit of information.. > I don't know if this change would enable inlining without LTO, though I think > the indirection through our C sourcef.c is rarely a performance factor for > Fortran users.
