Hi all...
I never saw any followup on this...?
It's one thing to break the ABI between the compiler and the gfortran
library; those can generally be expected to be in sync. It's another to
break the ABI between two *languages*, when there might be no such
expectation (especially if gcc does NOT break their ABI at the same
version number transition). Yes, the pre-ISO_C_BINDING method may be
old-fashioned, but it is a de-facto standard, and breaking it should not
be done lightly.
If you do proceed with changing the size, I would request that there at
least be a facility to reliably tell at compile time (on the C side)
which definition is being used, so I can adjust our macros accordingly.
Our code does depend on the size, and it has to cross-platform (and now,
if this change is made, cross-version), so with this change I would have
to support both int and size_t.
A C-side preprocessor symbol definition would do the trick. Of course
that assumes the versions of gcc/g++ and gfortran are in sync, which is
never guaranteed. But that assumption is better than nothing. Unless
someone has a better idea...?
Perhaps it might be best to wait until a time when gcc is also breaking
their ABI, so that there's no question of code (on either side) working
across the transition...?
Thanks...
-Bob
P.S. I'm just a lurker here, but I lurk specifically to look for things
that will break our code base, like this.... ;-)
Bob.Deen @ NASA-JPL Multimission Image Processing Lab
bob.d...@jpl.nasa.gov
On 12/12/16 10:26 AM, Bob Deen wrote:
However, this will also affect people doing C->Fortran calls the
old-fashioned way without ISO_C_BINDING, as they will have to change
the string length argument from int to size_t in their prototypes.
Then again, Intel Fortran did this some years ago so I guess at least
people who care about portability to several compilers are aware.
We do a ton of this (old fashioned c-fortran binding) and changing the string
length argument size will have a big impact on us. We don't use the Intel
compiler so we never noticed a change there.
Is there really a use case for strings > 2 GB that justifies the breakage? I certainly
understand wanting to do it "right" but I'm probably not the only one with
practical considerations that argue against it if there are no compelling use cases.
Thanks...
-Bob
Bob Deen @ NASA-JPL Multimission Image Processing Lab
bob.d...@jpl.nasa.gov
