gfc_offset question (32 vs. 64 bits)

[Jonathan Lennox]

Steve Ellcey writes:
> Does libgfortran (or any other GCC library) offer a way to pass compiler
> option information into a library so it could be used to change the
> libraries behaviour?  I guess one could invent a new interface to do
> this, I was wondering if there was any existing precedence.

I think the most straightforward solution would just be to link in an
additional library before libgfortran.

My suggestion: define functions

gfc_offset _gfortran_read_us_head(gfc_unit*);
gfc_offset _gfortran_read_us_tail(gfc_unit*);
void _gfortran_write_us_head(gfc_unit*, gfc_offset);
void _gfortran_write_us_tail(gfc_unit*, gfc_offset);

defined as extern functions in libgfortran, and call them from io/transfer.c
as needed.  (Tweak as necessary to get error handling right.)

The standard versions can just read and write raw gfc_offset values, as now,
assuming that's the desired standard behavior, but a user can optionally
link in a library which defines alternate versions of these functions.
E.g. "gfortran -o myprog myprog.o -lhp-style-unformatted-files".

As long as these libraries are linked before libgfortran, the linker ought
to pick up the user's versions of these functions, not libgfortran's.  (This
may require a bit of shared library hacking in order to get this to work on
all shared library implementations.)


This should allow users to use any unformatted-sequential format they need;
GCC could even come with a few libraries implementing common formats.  It's
indefinitely extensible by users, with the only overhead being a few extra
function calls.  Behavior is still deterministic, with no "check your env
settings" issues causing user confusion, and no compiler modifications are
necessary.

Does anyone see any difficulties with this proposal?

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu