写完了后面的部分，开始写正文

#JavaScript 细致考题：有没有熟悉 DOM API 的人指出，这程序哪里出错了？

发上 GitHub.

小说还真是不好写啊…… 我大概是在屏幕前反而没什么想法了 😟……&
打字速度到还不是问题，因为我想情节的速度就很慢……

🥶 跑路先……

#INFO #NEWS #Freedom 感动

#通知

目前集群基本设置已经完成，备用节点应该已经恢复

小科普：一只狗的寿命通常在 10 – 13 年之间

#security #google Chrome 新 0day (audio component, use-after-free) (CVE-2019-13720)
影响版本 <=78.0.3904.87
据说已经牛逼到可以沙箱（当然我不知道是哪里的沙箱）遁出、甚至可以 RCE 了

很辣鸡的事情……

The exploit attempts to perform numerous operations to allocate/free memory along with other techniques that eventually give the attackers an arbitrary read/write primitive. This is used to craft a special object that can be used with WebAssembly and FileReader together to perform code execution for the embedded shellcode payload.

The exploit first tries to trigger UaF(use-after-free) to perform an information leak about important 64-bit addresses (as a pointer). This results in a few things: 1) if an address is leaked successfully, it means the exploit is working correctly; 2) a leaked address is used to know where the heap/stack is located and that defeats the address space layout randomization (ASLR) technique; 3) a few other useful pointers for further exploitation could be located by searching near this address.

https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/

chrome漏洞，建议立刻升级

#Google is warning Windows, Mac, #Linux users to update their #Chrome browser (to 78.0.3904.87) immediately due to a security vulnerability (CVE-2019-13720) that attackers are actively exploiting in the wild to hijack computers.

woc，找居然到了

写不下去了，我打算在修了我的 Doku 后写一门 JVM 脚本语言…… 即便我还有其他事情可以安排

我觉得那些真的好有意思，写文字不仅慢，而且好没意思……
所以大概我是写不下去这篇『小说』了吧……
不过本小说是『实用』小说，所以不需要写太多，只要有用就好。

说起来，这篇文章的脚本我不是不想用 ES6，可是我这本来 GitHub Pages 的 Jekyll build 也不能用插件…… 我也不想用什么 CI……
自己在本地编译又有点麻烦，而且导致一些问题，非常不爽啊，我很讨厌 for(var i... 和到处 function(it) ....

本文提供 waits.js, toc_tree.js, article_split.js, nsfw_switcher.js, night.js 插件来提升阅读体验，都是我从零彻底重写的
其实里面有很多复用做的并不好，比如说我手写了『交集 (intersection)』算法（其实是 comple…… 补集），比如

inline fun enableOn<reified W>(k: Element.ID) = W(helem(k)).also { it.enable() }

因为没有 T.prototype.also(op: (T) -> undefined) 我只能写成

function enableOn(k, w) {
var inst = new w(k); inst.enable();
return inst;
}

总觉得怪怪的，我的 tocTree 也可以利用 tocTree.config.onHeading(layer, hl); tocTree.config.onItem(layer, e) 来增加扩展性，可我觉得意义不大

不过我的 toc 递归倒是还蛮舒服 parseRec(div, mut i0, mut lev) -> [int, Subree]

我要给 Dokuss 库修一个严重的 bug，这个 bug 导致它不能正常读取有符号的多字节整形

这个问题是因为 JVM 的 shl/shr 没有按照我的预期，设置和移除符号位的原因

(0x80_00_00_00).shr(31)

这个数，它实际上已经是 kotlin.Long 了（超过了 31 位），不过看起来是 32 位的样子

它的第一个十六进制位用二进制表示是 0b1000，首位不为零
而这个数值左移一位，就是 0b0100，0x7

(0x80_00_00_00).toInt() // -2147483648

不过如果用 Long 操作，符号位会被考虑进转化结果里

但是很多时候是用 Int 的，这样一些东西就不能设置好了…… 不过目前好像还没确定是这个问题？

from struct import pack, unpack

def swap(i): return unpack('<i', pack('>i', i))

欸

(1).shl(31) // -2147483648

不对啊！完全符合预期好不好？到底是哪里出了问题？

🤔 我对 UTF-16 读取不好的问题，已经完全放弃了，看起来像是我漏了什么，包括我用 radare2 看 hex 的结果都不一样

果然是 UTF-8 和 UTF-16 编码不兼容的问题…… 我这里 r2 上看到的『恭喜发财』是 3*4 字节，也难怪了

效果很好，不过组合解析器好像有问题……

本来这次回来也是要解决一个关于 signbit 的有点难受的 bug 的，看起来是不必解决了，虽然这个问题我想解决的话也有点勉强……

手工测试通过……