158778 2016-06-15 01:51:28 -0700 Don't leak the names of [private] functions in JS built-ins 2016-06-22 02:05:39 -0700 1 1 1 Unclassified WebKit Bindings WebKit Nightly Build Unspecified Unspecified NEW P2 Normal --- 143211 1 adam.bergkvist webkit-unassigned cdumez joepeck youennf oldest_to_newest 1202529 0 adam.bergkvist 2016-06-15 01:51:28 -0700 If I implement a function add() as a JS built-in based on a private function @privateAdd(), I need to duplicate all type checking done in @privateAdd() to prevent error messages to reveal the "privateAdd" name. For example: "Argument 1 ('item') to Bar.privateAdd must be an instance of FooItem" The approach with adding a native JS function to both a 'name' and a '@name' slot, mentioned in [1], makes this less of an issue. [1] https://bugs.webkit.org/show_bug.cgi?id=158777 1204427 1 adam.bergkvist 2016-06-21 22:35:16 -0700 Since [1] is fixed now, I'm OK with closing this as WONTFIX. [1] https://bugs.webkit.org/show_bug.cgi?id=158777 1204468 2 youennf 2016-06-22 01:39:42 -0700 Let's keep it open for now. There may be cases where this issue might arise again. Also, usually, the caller of the private method should ensure that parameters passed to the function are all fine. In such a case, the checks should become assertions. 1204475 3 adam.bergkvist 2016-06-22 02:05:39 -0700 (In reply to comment #2) > Let's keep it open for now. > There may be cases where this issue might arise again. OK with me. > Also, usually, the caller of the private method should ensure that > parameters passed to the function are all fine. In such a case, the checks > should become assertions. I haven't looked into the effect of the UNLIKELY macro, but it sounds like something we might want to use it if we still want to keep the "second step argument" checks in native code.