Re: gfc_offset question (32 vs. 64 bits)

[Paul Brook <paul at codesourcery dot com>]

On Wednesday 15 December 2004 18:36, Jonathan Lennox wrote:
> 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 seems a good idea.  I'm a bit worried about the shared library issues 
though.

I have different suggestion:

define a library call that specifies the library behaviour. The user can then 
either call it explicitly from their code, or link in an object with an 
__attribute__((constructor)) function that does it for them. The big 
advantage is that it avoids all shared library and linking issues. The 
downsite is that is doesn't allow a third party custom formats. However new 
formats can easily be added to libgfortran with minimal maintenance cost, so 
this probably isn't an issue.

Paul