[PATCH] PR 78534 Change character length from int to size_t

[Bob Deen]

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.Deen@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.Deen@jpl.nasa.gov
>
>