[quickjs-devel] Re: [PATCH] Add ability to freeze objects from C

  • From: Chris Cowan <agentme49@xxxxxxxxx>
  • To: quickjs-devel@xxxxxxxxxxxxx
  • Date: Thu, 5 Sep 2019 13:25:40 -0700

If you want to be sure you can reference the original Object.freeze
implementation in C code later, you could do the same solution you could do
in JS: save a reference to the original function at startup before anything
else runs in the JS context.

On Thu, Sep 5, 2019 at 10:23 AM Ondřej Jirman <deibeemoocheuguhumoh@xxxxxx>
wrote:

On Thu, Sep 05, 2019 at 06:18:25PM +0200, Saúl Ibarra Corretgé wrote:
IMHO that’s generally a Bad Idea (TM). Just look at all the hoops Node
has to
jump through with their “primordials” module just so they can get the
original
behavior in the internal modules.

Also, arguably the stdlib behavior should be dictated my the
implementation
, not the user. If I want to give the user a frozen object I think I
should be
able to.

Yes, if you're looking at it from the PoV that you're writing a library
that
nothing from outside should be interfering with.

But not really if you're generally mixing C and JS functions as a part of
a larger app, and C/JS functions are largely equivalent in scope, where
just
because some function is written in C doesn't mean it should somehow
escape the fact that something decided to override some Object.* function.

Though, yeah. If QuickJS C api will expose those methods, it should not
call
whatever's in Object.freeze atm, but just freeze the object.

And anyway, runtime maleability of any object makes JS quite interesting,
compared to other languages. I regularly use this fact to inspect other
people's
web apps, or to block use of potentially unsafe functions, like innerHTML.

regards,
        o.


My 2 cents.

-Saúl

On 5 Sep 2019, at 12:28, Ondřej Jirman <deibeemoocheuguhumoh@xxxxxx>
wrote:

Hi,

On Thu, Sep 05, 2019 at 10:01:09AM +0200, Saúl Ibarra Corretgé wrote:
Hey there,

I've come to need to freeze an abject that I'm exposing on a C module
(think of scriptArgs). I don't want that object to be changeable, so
I'd
like to Object.freeze it, but from C.

The attached patch does just that. I hope it (or a variant of it) can
be
included in a future release.

JS has quite a number of functions in its "standard library".
Object.freeze
is just one of them. These can be "overriden" or replaced, if you
will, by user
code.

In C API you may want to call the original function or the user
provided one.
There's no telling which one, in general.

The API you suggested will always call the original function. It may
or may
not be what the user of the C API expects. The application as a whole
may
want either behavior.

For example you'll no longer be able to do:

Object.freeze = function(o) {
   return o;
};

to disable freezing globally, or to modify Object.freeze function to
add
logging on what objects are being freezed globally for quick debugging.

You may want the behavior you suggested for the C API, but is it
desirable
in general?

regards,
   o.


Cheers,

--
Saúl

diff --git a/deps/quickjs/include/quickjs.h
b/deps/quickjs/include/quickjs.h
index 206516b..e6e5959 100644
--- a/deps/quickjs/include/quickjs.h
+++ b/deps/quickjs/include/quickjs.h
@@ -903,6 +903,8 @@ int JS_SetModuleExport(JSContext *ctx,
JSModuleDef *m, const char *export_name,
int JS_SetModuleExportList(JSContext *ctx, JSModuleDef *m,
                           const JSCFunctionListEntry *tab, int len);

+JSValue JS_ObjectFreeze(JSContext *ctx, JSValue obj);
+
#undef js_unlikely
#undef js_force_inline

diff --git a/deps/quickjs/src/quickjs.c b/deps/quickjs/src/quickjs.c
index d5c1c83..08146d6 100644
--- a/deps/quickjs/src/quickjs.c
+++ b/deps/quickjs/src/quickjs.c
@@ -50153,3 +50153,7 @@ void JS_AddIntrinsicTypedArrays(JSContext
*ctx)
    JS_AddIntrinsicAtomics(ctx);
#endif
}
+
+JSValue JS_ObjectFreeze(JSContext *ctx, JSValue obj) {
+    return js_object_seal(ctx, JS_UNDEFINED, 1, (JSValueConst
*)&obj, 1);
+}






Other related posts: