[siracozmen01]

Problem

m3CreateVehicle takes a wheel direction whose squared length lies between 0.81 and 1.21 and stores it normalized. That happens in InitWheel in src/vehicle.c, the only call that writes a live wheel's direction. The step then uses the stored direction as a unit vector for the suspension's cast and forces.

m3World_Restore checked the stored direction only with the create's own check: WheelsValid in src/snapshot_bounds.c calls m3WheelDefCheck. It therefore took any direction in that wide band. On main, a snapshot whose stored wheel direction was scaled to length 0.95 restored with m3_success, so a restored wheel could push along a vector the library never stores (#414).

Change

WheelsValid also requires the stored direction's squared length to lie within 1e-5 of 1, so restore refuses with m3_errorFormat any direction create would not have stored.

The band is set by measurement. Over 20 million random directions in the create band, the worst normalized one is 4.17e-7 from unit squared length. That leaves the band about 24 times wider than what the normalization leaves, so no state the library writes is refused.

No step, result or golden hash moves: the check only refuses snapshots the library cannot produce.

Verification

• TestWheelDirectionLength in test/test_restore_bounds.c edits the first wheel's stored direction in a snapshot:
  • -1 and -1.000002 along its axis restore;
  • -0.95, which create takes and would normalize, and -1.00001, just past the band, are refused with the world left as it was and no misuse counted.
• With the unit check removed from WheelsValid, both refusals fail in that test. With it, gcc-14 Debug with -DMAUL3D_WERROR=ON passes all 77 tests.
• tools/check.sh pr passes in the main checkout on this head: 77 and 75 tests, and fuzz with no finding.

Closes #414

[siracozmen01]

Review at 8da28de: ready, with one point not verified. No findings. Read, not run.

Writers of a wheel direction, as far as I can read them:

• InitWheel (vehicle.c:138) is the only writer in vehicle.c for a live wheel. Its single caller is create (line 195). For a def wheel it stores direction * (1 / sqrtf(dot)), and a slot past the wheel count gets exactly (0, -1, 0).
• m3DestroyVehicleInternal zeroes the direction (line 223), but only for a vehicle that is no longer alive.
• VehiclesValid skips any slot that is not alive, and WheelsValid walks only w < wheelCount. So the zero and the past-count slots never meet the new band.
• The public vehicle API (vehicle.h) has no setter for a wheel's geometry: only commands, tank commands, drivetrain and gear.
• Restore copies the stored bytes, which is exactly what this check now bounds.

The band:

• A float normalization leaves the squared length off by a few ulps of 1, around 1e-6 at worst. That includes m3Dot3 rounding at the check, and a snapshot taken on a platform that contracts to FMA differently. The 4.17e-7 measured is consistent with that, and 1e-5 is wide of it.
• !(d2 > ... && d2 < ...) also refuses NaN, which m3WheelDefCheck's finiteness test already did.

Test:

• -0.95 (d2 = 0.9025) and -1.00001 (d2 about 1.00002) both lie in create's 0.81 to 1.21 band, so main restores them. Both refusal assertions therefore fail on main for the right reason.
• -1.000002 (d2 about 1.000004) checks that the band does not refuse a near-unit direction.
• The world-unchanged and no-misuse checks match restore's contract.

Not verified: that no source outside vehicle.c and the snapshot code writes vehWheelDir (I read vehicle.c whole, but cannot search the tree). A search for vehWheelDir across src/ that finds only vehicle.c's two writes and the snapshot's read and copy would settle it.

The body has Problem, Change and Verification.