On 12/19/16 11:33 AM, Janne Blomqvist wrote:
On Mon, Dec 19, 2016 at 6:43 PM, Bob Deen <bob.d...@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.
Apologies if I offended (and to Steve too). I see all the deliberation
you're doing for breaking the language->library ABI, and appreciate
that. It's well-justified. My point, however, is that with this change
you are breaking an entirely *different* ABI - that between Fortran and
C - and the sum total of discussion was one message from Janne pointing
out that it was breaking (thanks for that heads-up, I had missed it!),
with no followup. Janne, you yourself in that message questioned the
need for large strings, and had no use cases in response to FX's inquiry.
Now that I think about it, it's not even an ABI change, it's an API
change... requiring a code change, not just a recompile.
So in this case, this change represents (AFAIK) the only breakage in the
old-style Fortran<->C ABI/API, with no known use cases... and thus my
question about whether it's justified. It's a fair question. I'm not
arguing the language->library ABI at all.
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.
I understand that. It just seems that opening up an entirely *new*
ABI/API for breakage deserved a little more discussion. Y'all are the
ones doing the (mostly volunteer) work on gfortran, and I appreciate it.
You're also much more invested in the future of the language than I
(yeah, it's mostly legacy code for us). If you end up deciding that it
needs to be done, then I'll deal with it. I just wanted to chime in
that there are users who will be affected. If I'm the only one, I
wouldn't want to stand in the way of progress - but also don't want to
get steamrolled if it's not an important change, or if there are other
affected users.
So... ARE there any other affected users out there??
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?
I wouldn't call it trivial by any means... it's tricky code I haven't
had to look at in 10 years. But in the end, probably doable.
Steve showed how you can do it for Fortran. From the C side, just
check the version from the __GNUC__ macro.
I dislike having to check for version numbers (feels kludgy) but that's
a personal preference. That will probably work, with a bit of futzing.
Thanks for your attention...
-Bob
Bob Deen @ NASA-JPL Multimission Image Processing Lab
bob.d...@jpl.nasa.gov
