https://gitlab.synchro.net/main/sbbs/-/commit/a6a6f1316a4e656941b0cfe7
Modified Files:
exec/load/sha256.js
Log Message:
sha256.js: install a File.sha256_hex getter, as a real polyfill

The first cut only CONSULTED file.sha256_hex from inside sha256_of_file() -- which does nothing for a script author, who still had to call the free function. The load/*.js polyfill convention (array.js's Array.prototype shims) is to install the member itself when the build lacks it, so a script written against the eventual native API works today and switches to the C implementation the day it ships, with no call-site change.

So loading the file now defines a File.sha256_hex GETTER on File.prototype, guarded by `"sha256_hex" in File.prototype`. The native hash getters (md5_hex/sha1_hex) live on File.prototype via js_file.cpp's property table, so that property arriving there is exactly what makes the guard skip the shim and hand off to the C getter.

The getter is shaped to match the native family precisely, because a polyfill that behaved differently would be a trap once the real one lands: it is a property (not a method), it is undefined on a closed File, and it hashes the whole file regardless of the current read position while leaving that position untouched -- all verified against md5_hex. sha256_of_file(path) stays as an open/read/close convenience wrapper, so its existing callers are unchanged.

Verified: File.sha256_hex of "abc" == the sha256sum known answer, the getter
is undefined when closed, the read position round-trips, and a second load()
is a no-op.

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net