Bug(expr): divergences from CPython/spec

[crowecawcaw]

Describe the bug

Six silent-wrong-value divergences in openjd-expr: each expression evaluates successfully and returns a wrong result. None panic, so fuzzing and the existing 3,424 tests pass over them.

Discovered by fuzzing expressions and using equivalent between Rust and mwiebe's Python implementation as the oracle.

https://github.com/crowecawcaw/openjd-rs/actions/runs/30466242555/job/90624590862

Expected Behaviour

Values per the Want column below. #6 additionally needs a spec decision: CPython raises TypeError for PurePosixPath < str, so it can't adjudicate the direction — only that a < b and b > a must agree.

Two related spec questions, not bugs: whether path / '' keeps a trailing separator (posixpath.join says yes and this crate matches; PurePosixPath says no), and the #6 direction above.

Current Behaviour

#	Expression	Got	Want
1	9.2e18 % 0.1	0.0	0.09740867242801976
2	205.0 // 0.1	2050	2049
3	1e-7 (display)	1e-7	1e-07
4	center('ab', 5)	" ab "	" ab "
5	path('a\b') / '\x' (Windows)	a\b\\x	\x
6	path('/tmp/x') < 'ab'	false, but 'ab' > path('/tmp/x') is true	consistent

Root causes:

1. arithmetic.rs computes l - r*floor(l/r); the product cancels the dividend at large quotients. CPython uses fmod + sign correction.
2. (l/r).floor() rounds before flooring; 0.1 is slightly above one tenth, so the true quotient is just under 2050. Value only — spec line 1162 makes float // float -> int, so the int type is correct and CPython diverges.
3. format_float's .replace("e-0", "e-") strips the zero-pad C-style exponents require. Positive exponents are already correct.
4. let left = pad / 2; — CPython's marg & width & 1 makes the bias depend on the parity of both operands. Odd padding only. Not fixed by fix(expr)!: enforce memory and operation limits before building large string outputs #284, which rewrites center_fn's preflight but keeps this line; its test uses width 4, where both rules agree.
5. Root-relative right operand should replace a left with no drive (ntpath.join → \x). Drive and UNC branches are already correct.
6. The mixed-type arm loses operand order, so both directions claim the string is larger. Antisymmetry is violated regardless of intended direction.

Reproduction Steps

See the CI log linked above. Harness and corpus:
https://github.com/crowecawcaw/openjd-rs/tree/differential-harness/differential

Environment

openjd-expr at 99871a0 (upstream/main). Reproduced on Linux/CPython 3.13 and macOS/CPython 3.14.3 — not platform- or interpreter-specific.

[uberware]

On item 6 — the specification does adjudicate the direction, and the pattern is narrower than
"both directions claim the string is larger".

I hit the same bug independently, differential-testing an unrelated Go implementation against
openjd-model 0.11.1. Two things to add.

The direction is defined, even though CPython can't settle it

You note that PurePosixPath < str raises TypeError in CPython so it can only establish that
a < b and b > a must agree. The OpenJD spec fixes the semantics directly:

• §2.1.4 — "Ordering operators work on int, float, string, path, and bool types. T1
  and T2 may differ for compatible pairs (int/float and string/path); comparing other
  cross-type pairs is an error." So string/path is one of exactly two pairs ordering is
  required to accept across types.
• §1.2.5 — "string vs path: The path is converted to string for comparison."

Composing those: path(p) OP s must equal str(p) OP s. So the expected column can be
generated from the library itself by dropping the path() call, without needing a Python oracle
for this item.

The pattern: path-on-the-left is inverted, path-on-the-right is correct

Against your own example, with the string form as the control:

from openjd.expr import ExprType, evaluate_expression as ev
B = ExprType("bool")

ev("path('/tmp/x') < 'ab'", target_type=B)   # false   control "'/tmp/x' < 'ab'" -> true    INVERTED
ev("path('/tmp/x') > 'ab'", target_type=B)   # true    control "'/tmp/x' > 'ab'" -> false   INVERTED
ev("'ab' > path('/tmp/x')", target_type=B)   # true    control "'ab' > '/tmp/x'" -> true    correct
ev("'ab' < path('/tmp/x')", target_type=B)   # false   control "'ab' < '/tmp/x'" -> false   correct

Full matrix over /a vs /z, all four operators, both operand positions — every one of the
eight path-on-the-left rows is the exact negation of the string control, and every one of the
eight path-on-the-right rows matches it:

Expression	actual	control
path('/a') < '/z'	false	true	inverted
path('/a') > '/z'	true	false	inverted
path('/a') <= '/z'	false	true	inverted
path('/a') >= '/z'	true	false	inverted
path('/z') < '/a'	true	false	inverted
path('/z') > '/a'	false	true	inverted
path('/z') <= '/a'	true	false	inverted
path('/z') >= '/a'	false	true	inverted
'/a' < path('/z')	true	true	correct
'/a' > path('/z')	false	false	correct
'/z' < path('/a')	false	false	correct
'/z' >= path('/a')	true	true	correct

So it is not that the string is always treated as larger — the result tracks content, just
reversed, which is consistent with your "loses operand order" diagnosis: the comparison happens
with the operands in the wrong order rather than with a constant.

Two notes that may help when fixing it

Equal operands mask it completely. path('/a') < '/a' → false and path('/a') <= '/a' →
true are both correct, because inverting a comparison of equal values is invisible. A
regression test built on equal values would pass over this, which may be how it shipped. Any
test for the fix needs unequal operands in both positions.

Equality is unaffected, so the path/string cross-type machinery exists and works —
path('/a') == '/a' → true, path('/a') == '/b' → false. Only the ordering operators
reverse. The other compatible pair is also fine in both positions (1 < 2.5 → true,
2.5 < 1 → false), which isolates this to the path arm rather than to cross-type ordering
generally.

It propagates into list ordering elementwise, consistent with one root cause:

ev("[path('/a')] < ['/b']", target_type=B)   # false, should be true
ev("['/b']  < [path('/a')]", target_type=B)  # false, correct

Confirmed on openjd-model 0.11.1 (bundling openjd-expr 0.2.1) and on openjd-rs main at
d021564 built from source.