[Vm-dev] Add argvec and envec to sqVirtualMachine.[ch]? (was: FT2Plugin stops working with latest version)

[David T. Lewis]

On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
>  
> So, my proposal is to add
> TheArgC and TheArgV variables to exports table of system module,
> in same way as on windows it uses to expose stWindow variable:
> 
> 
> void *os_exports[][3] = {
> ...
>   {"","stWindow", &stWindow},
>   {"", "argc" , &theArgc }
> ....
> };
> 
> 
> then any plugin could lookup for given symbol using ioLoadFunction() function,
> and if there is no such symbol, then ok.. it will answer null , fail
> the primitive etc etc.
> 
> So, there is no need to change an API, just need to add few entries to
> os_exports structure.
> 

I have no objection at all, this sounds like a good idea to me :)

I need to ask though, is ioLoadFunction() the one that you added for
module security (some time in the last year or so I think)? That function
crashes on 64 bit, so we would need to sort that out (sorry I can't
look at source right now).

Dave

> 
> On 5 October 2011 17:13, Igor Stasenko <siguctua at gmail.com> wrote:
> > On 5 October 2011 16:41, David T. Lewis <lewis at mail.msen.com> wrote:
> >>
> >> On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
> >>>
> >>> On 5 October 2011 14:15, David T. Lewis <lewis at mail.msen.com> wrote:
> >>> >
> >>> > On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
> >>> >>
> >>> >> On 4 October 2011 14:17, David T. Lewis <lewis at mail.msen.com> wrote:
> >>> >> >
> >>> >> > I think there was an issue on some of the Mac platforms that required
> >>> >> > a compiler flag to force the compiler to make global variables visible
> >>> >> > (for the environment vector, etc). Is that the problem here? I do not
> >>> >> > have a Mac, but I'll try to help figure this out if I can.
> >>> >> >
> >>> >>
> >>> >> If i remember correctly, a Cocoa VM using different entry point for
> >>> >> main() function.
> >>> >> or have some other differencies, so you cannot just pass argc, argv
> >>> >> around, but you have to prepare them.
> >>> >>
> >>> >> If you remember, i proposed to make an API for exposing these
> >>> >> variables, so then not only OSProcess could access them
> >>> >> but any other plugin, without need of hackish linking flags, which
> >>> >> lead to confusion and too compiler/linker specific.
> >>> >
> >>> > Yes, I do remember this suggestion (although I can't find a pointer
> >>> > to it right now). I was mildly (not strongly) against it, but what do
> >>> > others think?
> >>> >
> >>> > My opinion was based on:
> >>> >
> >>> > 1) Setting a compiler flag to instruct it to make globals visible does
> >>> > not seem hackish to me. After all, most of the compilers we use work
> >>> > like that anyway, and it does not seem to be hurting them.
> >>> >
> >>> > 2) In order for the definitions to be visible for both a standard
> >>> > interpreter VM and a Cog/stack VM, the definitions would need to be
> >>> > added to the existing VM_PROXY_MINOR 9 definitions. That amounts
> >>> > to changing the defined interface without incrementing the version
> >>> > number, which definitely does seem hackish to me (though probably
> >>> > harmless).
> >>> >
> >>> > 3) The argument vector and environment vector are Unix constructs.
> >>> > Adding platform specific things to the interpreter interface should
> >>> > be avoided. Again, this is harmless since all of the major platforms
> >>> > mimic Unix in this respect, but still ... all the world is not unix ;)
> >>> >
> >>> > In any case, I do not have a strong opinion one way or the other,
> >>> > I'm just explaining my perspective on it.
> >>> >
> >>> > Other opinions? Esteban, you are probably most directly affected
> >>> > by this, do you have a preference?
> >>> >
> >>>
> >>> I have a strong opinion, that modules (and plugins) should access only
> >>> those symbols, which are explicitly exported by module(s) they using,
> >>> and not rely on something granted for free (implicitly visible via
> >>> linker/compiler flags).
> >>> Because if we don't care, then why do we need things like
> >>> InterpreterProxy at all, if any plugin could just link directly to any
> >>> VM function/variable in order to use it?
> >>> Apparently, such approach violates the module encapsulation, because
> >>> you no longer make sure that some symbols of your module is private
> >>> and should not be
> >>> accessed by others.
> >>
> >> If no one else speaks up, then your strong opinion will outvote my
> >> weak opinion.
> >>
> >>> Also, may i ask, why OSProcess needs those vectors at all?
> >>> Maybe a better solution would be to just avoid using them?
> >>> I think, that it should be a responsibility of main module to expose
> >>> those vectors, if it wants to, but not by a plugin. Because it again,
> >>> violating the encapsulation principles.
> >>
> >> OSProcess is full of stuff that I put in just because I felt like
> >> doing it. To be honest, I never expected it to be widely used by other
> >> people. And I certainly was not attempting to rise to any high standards
> >> of software purity ;) Having said that, I do think that it is important
> >> to avoid putting platform-dependent things into the VM and image. What
> >> I choose to put into my own plugin or my own project is my business
> >> (and the development of OSProcess was an example of that), but I do
> >> not think it is good for "features" in OSProcess to creep into the
> >> core system.
> >>
> >
> > I understand the situation around plugin, Dave.
> >
> > Yes, it is platform dependent. You can compile main module with
> > different entry point (non POSIX), where you don't have access to
> > argv/argc variables at all.
> > For instance windows WinMain() function does not have them.
> > But my point was more about who should take care about exposing those
> > symbols, not about whether all platforms should support this API or
> > not.
> >
> > So, the point is, that since argc/argv stuff are coming from main
> > module, then main module should care about
> > exposing (or not) these symbols, not the third-party plugin.
> >
> >
> >> Dave
> >
> > --
> > Best regards,
> > Igor Stasenko.
> >
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.