(j3.2006) Alternative binding label without C interoperability?
Clune, Thomas L. GSFC-6101
thomas.l.clune
Fri Sep 30 09:20:42 EDT 2016
> On Sep 29, 2016, at 8:41 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:
>
>> I?m assuming there are analogous procedures for Windows and other
>> ?exotic? OS?s.
>
> Yes for Windows (it has had DLLs for quite a long time). More exotic OS's
> do not necessarily have anything.
>
>>> If you're willing to limit yourself to dlsym and dlopen, and willing to
>>> limit yourself to using interoperable procedures, it is easy enough to do
>>> already.
>>
>> I would like to learn of it.
>
> Just use BIND(C,NAME=...). Then you know the name you need to pass to the
> dynamic loading routines.
Sorry - was reading too quickly. Missed your ?limit yourself to ?? clause. I?m on the same page.
>
>>> Well, it would be easy enough to have a "BINDING_NAME()" intrinsic
>>> function,
>>> specifically to enable dynamic loading (we could even require
>>> dlsym/dlload
>>> to work if they are supported by the processor, by referencing the Posix
>>> standard). That would probably be ok for external procedures, but not
>>> for
>>> module procedures. For module procedures one could just have an external
>>> procedure that called the module procedure.
>>
>> Yes - that would be acceptable. But I am a bit surprised by the
>> restriction given that we can use BIND(C) for other module procedures.
>
> The point is that BIND(C,NAME=anything but '') gives the module procedure a
> global identifier. This really makes it like a "special" external procedure
> that despite being external can still access the module's private parts.
Yes. This is actually what I want in my particular case. The procedure in question really just goes on to assign a few more procedure pointers (init, run, finalize) for each component. But those assignments can be done without any further issues. By having them be module procedures, we can use the same name for these in every component and again avoid name space collisions.
I agree that in general it is (mildly) undesirable to have a module procedure be accessible in this manner. But it fits our case nicely.
>
> Without BIND(C), a module procedure does not have any global identifier, so
> there is not necessarily anything that BINDING_NAME() could return. As
> mentioned before, this was actually the case on some older compilers (and
> could well be the case on some current ones, though I am not aware of any).
> Name mangling is just one way that compilers have of making it look as
> though module procedures do not have global identifiers.
Understood.
- Tom
>
> Cheers,
> --
> ........................Malcolm Cohen, Nihon NAG, Tokyo.
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
More information about the J3
mailing list