Artifact [0b9f7e96c7]

Artifact 0b9f7e96c77a5cbd89696ac7ae16f41c607b61d53a1fc063e5cd15d920786426:

• File internal/fsltype/julian_long_wasm.go — part of check-in [f7eb80beae] at 2026-10-29 03:06:14 on branch main — perf(fsltype): format a 53-bit text Julian day in float64, no math/big

  Fossil's %.17g of a text Julian day is computed in the platform's long double, which this package emulates with big.Float at that precision. A 53-bit long double is a double, and big.Float at 53 bits with round-to-nearest-even is exactly IEEE double arithmetic over this range, so that case (wasm, macOS arm64, Windows) is now computed in float64, each product converted explicitly so none fuses into a multiply-add.

  The big.Float path remains for the 64- and 113-bit long doubles and is left out of wasm builds, whose long double is 53 bits; a wasm TinyGo binary loses math/big's floating point, about 5 KB gzipped. A test checks the float64 path against the big.Float one at 53 bits over 50,000 random times and every ~1 s of three days, and the existing fossil-binary sweep passes unchanged. Stored times do not change. (user: [email protected], size: 359) [annotate] [blame] [check-ins using] [more...]

//go:build wasm

package fsltype

// printf17gLong is never reached in a wasm build: longDoubleBits is 53
// there, which fossilPrintf17g computes in float64. Leaving out the
// big.Float emulation keeps math/big out of the binary.
func printf17gLong(v0 float64, prec uint) string {
	panic("fsltype.printf17gLong: a wasm build has no extended long double")
}