| 12:24 | <Jack Works> | does anyone know any tools to catch inconsistent sort functions in codebases? like some sort of linting |
| 12:59 | <Ashley Claymore> | (a, b) => Math.random() > 0.5 ? -1 : 1 |
| 13:00 | <Ashley Claymore> | I could swear some browsers do (or used to) throw if they detected an inconsistent sort while running their algo |
| 13:12 | <Jack Works> | Enforced PartialOrd 🤔 |
| 13:30 | <Ashley Claymore> | In ES5 said "If comparefn [..] is not a consistent comparison function [...] the behaviour of sort is implementation-defined." - which would have allowed an engine to throw if it detected it |
| 13:31 | <Ashley Claymore> | now we seem to only say that the "SortOrder" is implementation defined. So I think throwing would no longer be spec compliant |
| 13:56 | <jmdyck> | ES6 (draft 27) changed "the behaviour of sort is implementation-defined" to "the sort order is implementation-defined" in that sentence. |
| 15:47 | <snek> | What do you mean by inconsistent sorts? |
| 17:14 | <snek> | ES6 (draft 27) changed "the behaviour of sort is implementation-defined" to "the sort order is implementation-defined" in that sentence. |
| 17:14 | <snek> | nothing threw thankfully :) |
| 17:15 | <Ashley Claymore> | and they did that accidentally? |
| 17:15 | <snek> | i put this together to detect inconsistent functions https://engine262.js.org/#gist=49dc7f2fb9ff3095d401f22529b4443f |
| 17:15 | <snek> | and they did that accidentally? |
| 17:16 | <Ashley Claymore> | it sounds more like an esoteric JS quiz question |
| 17:17 | <snek> | yeah we need more implementation defined behavior |
| 17:17 | <snek> | like those funny c programs |
| 17:17 | <Ashley Claymore> | evalAsYouLike(...) |
| 17:18 | <snek> | technically eval('debugger') returns an implementation defined value |
| 17:18 | <snek> | i don't think anyone does anything interesting with it |
| 17:19 | <snek> | we should specify that to return undefined lol |
| 17:19 | <snek> | or empty i guess |
| 18:29 | <bakkot> | ubsan, but for javascript |
| 19:08 | <shu> | idbsan |
| 19:23 | <rkirsling> | absan (Annex B sanitizer) |
| 20:37 | <snek> | ubsan, but for javascript |
| 20:38 | <bakkot> | there's just not that much implementation-defined behavior |
| 20:38 | <bakkot> | and a majority of it is stuff like the precision of math operations and number parsing, which no one wants to audit |
| 20:39 | <bakkot> | array sort comparators are probably genuinely the only case worth worrying about |
| 20:39 | <snek> | oh yeah i don't literally mean only finding ID/UB, i mean finding weird bugs just due to js being weird |
| 20:40 | <bakkot> | eslint has some of those checks, as does typescript |
| 20:40 | <bakkot> | but they're static, yes |
| 20:41 | <snek> | maybe a good one would have been catching the __proto__ bugs that every json handling http library has |
| 20:42 | <bakkot> | by adding a check at every single computed property assignment? |
| 20:42 | <bakkot> | I mean... I guess? but you'd still need to actually run into the bad code for it to be triggered |
| 20:42 | <bakkot> | that one seems like a better use case for a fuzzer |
| 20:43 | <snek> | yeah these all require fuzzing |
| 20:43 | <snek> | or letting it loose on your users 😄 |
| 20:43 | <bakkot> | ah, sure |
| 20:43 | <bakkot> | a ubsan designed to be used with a fuzzer would be valuable, for sure |
| 20:44 | <snek> | at discord we have a system that scans for a11y problems as users use the app and reports them |
| 20:44 | <snek> | its an interesting concept |
| 20:47 | <bakkot> |
on further consideration you'd do this by overriding |