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

[Janne Blomqvist]

On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen <Bob.Deen@jpl.nasa.gov> wrote:
> 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.

First: No, it's not done "lightly". And secondly, cross-language
interfacing is always tricky, which is why most languages, including
Fortran with ISO_C_BINDING, have devised standardized ways for
communication with C so users don't need to rely on various cross-call
mechanisms that are not guaranteed to work.

That the charlen is a hidden argument added at the end of type int is
AFAIK a fairly common implementation choice, though I'm not sure if it
can be called a de-facto standard.  Considering that Intel Fortran has
switched to size_t several years ago (5-ish?), and AFAIU it's the most
used Fortran compiler around in addition to GFortran, and the world
hasn't crashed down due to it, I suspect users can adapt to the change
with relatively little drama.

That gcc would change it's ABI at all, and especially in conjunction
with gfortran, is a pipe dream.

C changed to use size_t for string lengths instead of int with ANSI C
in, what, 1989.  With 2-socket servers, typically used e.g. in HPC
clusters, today easily having hundreds of gigs of RAM, limiting
GFortran char lengths to 2 GB for all eternity in the name of
compatibility seems quaint at best. Maybe in your organization Fortran
is legacy code that YE SHALL NOT TOUCH, but GFortran also has to cater
to users who have chosen to write new code in Fortran.

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

Oh, you have macros rather than hard-coded int all over the place?
Shouldn't it be a relatively trivial affair then to define that macro
appropriately depending on which compiler and which version you're
using?

Steve showed how you can do it for Fortran. From the C side, just
check the version from the __GNUC__ macro.

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

Well, if you add the option to use size_t you should be able to use
ifort as well. :)

> 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...?

Yeah, I think that's the best idea.

Another option would be to implement some kind of
-fcharacter-length=[int,size_t] command-line option. But that would
make the patch a lot more complicated since one would need to typecast
the character length argument when calling libgfortran. And, you'd
still have to have some version-dependent checks to see if gfortran
would accept that option. And like other similar options like
-fdefault-this-or-that it would change the ABI, so code compiled with
that option would be incompatible with code compiled without it. So in
the end I'm not convinced such an option would actually make life any
easier for our users.

> 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...?

AFAIK there is no ABI change planned for gcc. For better or worse, the
C language is relatively stable and doesn't change much.

> P.S.  I'm just a lurker here, but I lurk specifically to look for things
> that will break our code base, like this....  ;-)

Well, then you ought to be aware the ABI cleanup page on the wiki,
where the char length issue has been listed for, what, 5 years or so,
so it can't really be a surprise that it will happen at some point,
can it...?

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



-- 
Janne Blomqvist