collinstocks

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

104 Neutral

About collinstocks

  • Rank
    Newbie
  1. Object handle getting released; causing a null pointer error?

    Sorry for coming into this late, but could this possibly be resolved (in this particular case, and maybe in others) by having the gc preferentially releasing handles that are members of objects with no destructors?   That is, in this case the gc would first release the Character::avatar handle. At this point, the Avatar would have no more references, and could be destructed safely.   Of course, this solution doesn't quite work if you have circular references between classes that each have destructors, but then that is the programmer's own fault, right?    This method of breaking circular references is used by Python and the Boehm GC, although the way each of these handle the case of circular references among objects that all have destructors is to never collect the objects . . . I think that your solution is better in this case. Or, perhaps, throw an exception and refuse to run the destructors. That sounds more complicated, though.
  2. I am planning to create an application which is similar to a web browser in some respects: it executes untrusted code in order to manipulate its behavior. In a web browser, this would be the display. In my application, it may be the display or possibly some other things. What is manipulated is not really very important.   AngelScript seems to be exactly what I am looking for: it is fast, its syntax is familiar, it can be embedded in an application, it supports multiple contexts (I forget the technical term you use in your documentation), it has good documentation, and it is sandboxed---that is, the script will only have access to the functions I give it access to.   I just had a few questions about the safety of running untrusted AngelScript code, and specifically the bytecode.   If I provide the AngelScript environment with the function with prototype "void print(const string &in)" (as per an example in the documentation), what is the behavior of a script which calls "print(0)"? Will this fail to compile to bytecode? I would assume that this would probably be the case.   How about a different scenario: An evil person (Eve) provides the AngelScript environment with "void print(const int &in)" and compiles her program which calls "print(0)" to bytecode. She then exports the bytecode and sends it over a network to me.   I then load the bytecode into an AngelScript VM which is provided the original function with prototype "void print(const string &in)" instead of Eve's version. What is the behavior in this case?   More generally, is it safe to load untrusted bytecode into the AngelScript VM assuming that I only provide the AngelScript environment with safe functions? Is there any unrestricted memory access that the bytecode is capable of performing? Is it able to, for example, treat integers as pointers and follow them, or free a pointer and then follow it, or double-free a pointer?       tl;dr: Can I execute untrusted AngelScript bytecode sent from an untrusted server, or should I compile AngelScript code at the client end before running it?       Edit (answer): According to "Things to remember" on this page in the documentation, it is not safe to execute untrusted bytecode. I am really grateful for the extensive documentation you have created!