I have no issue with JS being able to crash SilkJS. In fact, I see it as a feature. The whole point of SilkJS is to provide a C-like and low-level Linux/OSX programming environment using JavaScript.
In C, you can crash your programs as trivially as: fwrite(buf, 10, 1, (FILE *)0xdeadbeef); The philosophy of SilkJS is that you can do likewise. However, the low-level bindings do return opaque handles to things as External::New() type things, and I implement JavaScript classes and methods that wrap the low-level bindings and add sanity and error checking of the arguments. Consider these C++ bindings to malloc: https://github.com/mschwartz/v8t/blob/master/src/binary.cpp vs. this JavaScript wrapper for those bindings: https://github.com/mschwartz/v8t/blob/master/modules/binary/index.js I fully understand the dynamic C++ class pattern in your link below, but I absolutely do not want to use it (for the most part). The cost of using it is obfuscating the implementation of such classes, as they need to be compiled and linked. The pattern I chose allows virtually all the code you'd require me to write in C++ to be coded in pure JavaScript, except for as thin a layer of glue functions to convert JS arguments to C parameters/call a library/OS function/return JS object. I expect people who use a server-side JavaScript platform to know JavaScript. I do not expect them to know C++. On Friday, September 7, 2012 5:50:34 AM UTC-7, Sven Panne wrote: > > After several discussions, it is not so clear anymore what to do. First of > all, SilkJS does not follow https://developers.google.com/v8/embed#dynamic on > how to handle foreign (i.e. C/C++) pointers when embedding v8. The return > value of External::New is supposed to live in an internal field, but it is > *not* a valid JavaScript value, it is just a Foreign in disguise, sometimes > optimized to a Smi. Our v8.h header is very confusing regarding this fact, > and having External as a subclass of Value is basically wrong. Furthermore > Value::IsExternal is completely broken. I can see 2 ways of fixing things: > > * Keep External's implementation basically as it is. i.e. either a Smi > or a Foreign. If we do this, we should not keep External as a subclass of > Value (perhaps a subclass of Data?) and we should remove the IsExternal > predicate. This means that e.g. SilkJS has to change, following > https://developers.google.com/v8/embed#dynamic. As it is, one can easily > crash SilkJS by pure JavaScript. > > * Make External basically a convenience wrapper for a JavaScript object > with an internal property containing a Foreign. This way we could keep > External a subclass of value and we could fix IsExternal. The downside is > that all code already following > https://developers.google.com/v8/embed#dynamic would basically do a > useless double indirection, punishing people following that guide. > > We will discuss these options, there are good arguments for both of them... > > Cheers, > S. > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
