{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma262/issues/635","repository_url":"https://api.github.com/repos/tc39/ecma262","labels_url":"https://api.github.com/repos/tc39/ecma262/issues/635/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma262/issues/635/comments","events_url":"https://api.github.com/repos/tc39/ecma262/issues/635/events","html_url":"https://github.com/tc39/ecma262/issues/635","id":164421456,"number":635,"title":"Should ECMAScript implementations be allowed to canonicalize NaN when writing into an Array?","user":{"login":"littledan","id":189835,"avatar_url":"https://avatars.githubusercontent.com/u/189835?v=3","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":22,"created_at":"2016-07-07T22:27:16Z","updated_at":"2016-12-03T16:57:50Z","closed_at":null,"body":"V8 has several representations of Arrays based on different kinds of unboxed content, called ElementKind. One ElementKind is FAST_HOLEY_DOUBLE_ELEMENTS. With this kind, the Array may contain holes (missing properties which delegate to the prototype), but all non-hole elements are unboxed doubles (Numbers). The trick is to canonicalize NaNs when written into such an array, and use a particular NaN value for \"the hole\" to indicate that a lookup on the prototype is needed.\n\nThis implementation technique violates the ECMAScript specification because, in [SetValueInBuffer](https://tc39.github.io/ecma262/#sec-setvalueinbuffer), there is the following text:\n\n> An implementation must always choose the same encoding for each implementation distinguishable NaN value.\n\nI believe this text was written with the intent of creating the cross-cutting effect that NaNs should always carry around their payload, and only get a new payload when a \"new\" NaN is created. (We could use some better spec text here to back that intention with more clear mechanics, and I've promised to do that, except I want to get this other issue worked out first.) A big piece of motivation for that is to prevent information leaks, e.g., in writing properties to frozen objects.\n\nI'm wondering, is there a way that we could weaken this requirement? V8's practice of canonicalizing NaNs just in order to write them into certain objects seems to improve our performance, and it seems harmless to me, as I don't know of any information leaks that we're creating.\n\nFor a strawman: what if we simply removed that sentence and let SetValueInBuffer write whatever NaN representation it felt like? Is there another way we could convince ourselves that information leaks won't happen?\n\ncc @bakkot @anba @erights @leobalter @verwaest\n"},"comment":{"url":"https://api.github.com/repos/tc39/ecma262/issues/comments/264651077","html_url":"https://github.com/tc39/ecma262/issues/635#issuecomment-264651077","issue_url":"https://api.github.com/repos/tc39/ecma262/issues/635","id":264651077,"user":{"login":"jfbastien","id":298127,"avatar_url":"https://avatars.githubusercontent.com/u/298127?v=3","gravatar_id":"","url":"https://api.github.com/users/jfbastien","html_url":"https://github.com/jfbastien","followers_url":"https://api.github.com/users/jfbastien/followers","following_url":"https://api.github.com/users/jfbastien/following{/other_user}","gists_url":"https://api.github.com/users/jfbastien/gists{/gist_id}","starred_url":"https://api.github.com/users/jfbastien/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jfbastien/subscriptions","organizations_url":"https://api.github.com/users/jfbastien/orgs","repos_url":"https://api.github.com/users/jfbastien/repos","events_url":"https://api.github.com/users/jfbastien/events{/privacy}","received_events_url":"https://api.github.com/users/jfbastien/received_events","type":"User","site_admin":false},"created_at":"2016-12-03T16:57:50Z","updated_at":"2016-12-03T16:57:50Z","body":"Specifically, this can happen with x86's x87 stack load / store instructions `fldl` and `fstpl`. x87 has a bunch of issues, but it's used to pass floating-point values in the `cdecl` calling convention. We could still disallow NaN canonicalization on load / store, but I would suggest better research: this example should have been known, there may be others we're missing."}}
{"actor":{"display_login":"jfbastien"}}