[Vm-dev] #pragma export on/off
Igor Stasenko
siguctua at gmail.com
Fri Feb 20 04:06:58 UTC 2009
2009/2/20 John M McIntosh <johnmci at smalltalkconsulting.com>:
>
> Well the pattern used is like so where we ask the operating system to find
> the entry point secCanRenameImage in the SecurityPlugin
> which relies on the plugin either being external, or internal, and if the
> plugin actually has the secCanRenameImage.
> This code enables weak linking....
>
> sCRIfn = ioLoadFunctionFrom("secCanRenameImage",
> "SecurityPlugin");
> if (sCRIfn != 0) {
> okToRename = ((sqInt (*)(void))sCRIfn)();
> if (!(okToRename)) {
> /* begin primitiveFail */
> foo->successFlag = 0;
> return null;
> }
> }
>
Aha, i see.
The code like above insulting me, and if you remember my previous flow
of thoughts about it, i proposed to add a small API to VM, which lets
plugins/modules to publish symbols by themselves, without need in
relying on C linkage rules.
>
>
> On 19-Feb-09, at 7:52 PM, Igor Stasenko wrote:
>
>>
>> 2009/2/20 Eliot Miranda <eliot.miranda at gmail.com>:
>>>
>>> Hi All,
>>> anyone know what platform this pragma is aimed at, and whether we still
>>> really, really need it? It is the source of the bulk of my warnings in the
>>> cog interpreter and I'd love to nuke it.
>>> E.
>>>
>> +1 for nuking it :)
>> As i understand this pragma ensuring that given symbol will appear in
>> module exports table, so other modules could lookup this symbol and
>> call these functions directly.
>> I fail see how such functions could be called directly bypassing rules
>> which ensuring a level of safety for VM - like InterpreterProxy.
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
--
Best regards,
Igor Stasenko AKA sig.
More information about the Vm-dev
mailing list