fix(test): mark the bridge's real round trips broken on Windows (#56)

* fix(test): mark the bridge's real round trips broken on Windows

main was red on both Windows runners: 23 failures, all in
test_libpari_ext.jl, all in reals. Every other part of the bridge passes
there.

Cause. On Linux and macOS, GIAC renders a REAL at *that value's*
precision — 156 significant digits for a 512-bit value — and the global
`Digits` has no effect on it. The bridge reads a Giac REAL back by
decoding its printed decimal and relies on exactly that.

On Windows, GIAC honours `Digits` instead, default 12. Every real crossed
truncated to twelve significant digits:

    expected  3.1415926535897932384626433832795028842
    obtained  3.14159265359 0000062

at every precision asked for — 64, 128, 192, 256, 384, 512, 1024 all give
the same twelve digits, so it is a ceiling, not a rounding difference.
`Digits` governs GIAC's parser on Windows too, so
`convert(GiacExpr, ::BigFloat)` cannot even store a wide value: it lands
on DOUBLE rather than REAL.

Worth recording plainly, because it is the more useful lesson: the
decode *verifies itself* by re-encoding the candidate and comparing
printed forms, and that check was blind here. Re-encoding the truncated
value also prints twelve digits, the forms agree, and a wrong answer is
confirmed. The check establishes the printer's self-consistency, not its
fidelity; the two coincide only where the printer is faithful. A guard
that inspires confidence without providing it is worse than none.

The assertions are marked `@test_broken` rather than skipped, so the
suite errors if they start passing and tells whoever fixed the platform
difference to remove the marker.

The documentation claimed Giac's printer emits a REAL at the value's own
precision "rather than at a global setting", presented as measured fact.
It was measured on Linux only. Corrected, with a dedicated section, a
warning admonition on the reals section, and an entry in the limitations
list.

Not attempted here: raising `Digits` around the read, which might restore
Windows. That needs a Windows runner to judge and belongs on its own
branch — this one only stops main lying about the state of the tests.

* fix(test): mark the bridge's real round trips broken on Windows

main was red on both Windows runners: 23 failures, all in
test_libpari_ext.jl, all in reals. Every other part of the bridge passes
there.

Cause — a known ABI bug between the two binaries, not a Giac quirk and
not something this bridge can work around. `class gen` stored its tag as
a bitfield, `unsigned char type:5; unsigned char type_unused:3;`. GCC
fuses adjacent bitfield writes into one wider store and picks the bit
placement in a version-dependent way. GIAC_jll is built with GCC 8 and
libgiac_julia_jll with GCC 10, so they disagree about which bits hold
`type`: libgiac writes a gen tagged _REAL and the wrapper reads back
_DOUBLE_. The suite observes it directly:

    Expression: Giac.giac_type(wide) == REAL
    Evaluated:  DOUBLE == REAL

Everything else follows. Giac.jl believes it holds a Float64, prints at
the global `Digits` — default 12 — and every real crosses truncated to
twelve significant digits:

    expected  3.1415926535897932384626433832795028842
    obtained  3.14159265359 0000062

identically at 64, 128, 192, 256, 384, 512 and 1024 bits, because 53 bits
is all a mis-tagged DOUBLE ever had. Raising `Digits` would change
nothing: the precision is lost at the tag, not at the printer.

Fix in flight upstream: JuliaPackaging/Yggdrasil#13717 bumps GIAC_jll to
v2.0.2 with GIAC_TYPE_ON_8BITS=1, making `type` a plain byte at offset 0
and the ABI compiler-invariant, followed by a libgiac_julia_jll bump.
Same root cause as #22 and the probe in #26.

The assertions are marked `@test_broken` rather than skipped, so that
when both JLLs land the suite reports unexpected passes and tells whoever
did it to delete the markers.

One thing this did establish about the bridge itself: its decode verifies
itself by re-encoding the candidate and comparing printed forms, and that
check is blind here. Re-encoding the truncated value also prints twelve
digits, the forms agree, and a wrong answer is confirmed. The check
establishes the printer's self-consistency, not its fidelity — the two
coincide only where the tag is right. Worth stating, because I had
described that check in the docs as what makes a text-mediated step safe.

The documentation claimed Giac's printer emits a REAL at the value's own
precision "rather than at a global setting", presented as measured fact.
It was measured on Linux only. Corrected, with a dedicated section, a
warning admonition on the reals section, and an entry in the limitations
list.

Author: s-celles

CHANGELOG.md

@@ -7,6 +7,53 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- **The LibPARI bridge's real-number tests no longer fail the suite on
+  Windows**, and the platform difference behind them is documented rather than
+  hidden. `main` was red on both Windows runners with 23 failures, all of them
+  in `test_libpari_ext.jl`, all in reals.
+
+  The cause is not Giac and not the bridge: it is a known ABI bug between the
+  two binaries. `class gen` stored its tag as a bitfield, GCC fuses adjacent
+  bitfield writes with version-dependent bit placement, and `GIAC_jll` is
+  built with GCC 8 against `libgiac_julia_jll`'s GCC 10 — so libgiac writes a
+  gen tagged `_REAL` and the wrapper reads back `_DOUBLE_`. The suite observes
+  it directly: `Giac.giac_type(wide) == REAL` evaluates to `DOUBLE == REAL`.
+
+  Everything else follows. Giac.jl believes it holds a `Float64`, prints at
+  the global `Digits` — default 12 — and every real crosses truncated to
+  twelve significant digits, identically at 64, 128, 256, 512 and 1024 bits,
+  because 53 bits is all a mis-tagged `DOUBLE` ever had. Raising `Digits`
+  would change nothing: the precision is lost at the tag, not at the printer.
+
+  Fix in flight upstream:
+  [Yggdrasil#13717](https://github.com/JuliaPackaging/Yggdrasil/pull/13717)
+  bumps `GIAC_jll` to v2.0.2 with `GIAC_TYPE_ON_8BITS=1`, making the ABI
+  compiler-invariant, followed by a `libgiac_julia_jll` bump. Same root cause
+  as [#22](https://github.com/s-celles/Giac.jl/pull/22) and the probe in
+  [#26](https://github.com/s-celles/Giac.jl/pull/26).
+
+  One thing this did establish about the bridge itself: its decode *verifies
+  itself* by re-encoding the candidate and comparing printed forms, and that
+  check is blind here. Re-encoding the truncated value also prints twelve
+  digits, the forms agree, and a wrong answer is confirmed. The check
+  establishes the printer's self-consistency, not its fidelity — the two
+  coincide only where the tag is right.
+
+  The affected assertions are now marked `@test_broken` on Windows rather than
+  skipped, so that when the two JLLs land the suite reports *unexpected
+  passes* and tells whoever did it to delete the markers. Everything else
+  in the bridge passes on Windows: integers, rationals, complex numbers,
+  polynomials, vectors, matrices, refusals, variable names, the PARI stack
+  check and the piracy check. A `DOUBLE`, needing no more than twelve digits,
+  crosses correctly.
+
+  The documentation said Giac's printer emits a `REAL` at the value's own
+  precision "rather than at a global setting", presented as a measured fact.
+  It was measured on Linux only. Corrected, with a dedicated section and a
+  warning admonition on the reals section.
+
 ### Added
 
 - **Dependabot for the pinned GitHub Actions** (`.github/dependabot.yml`),

docs/src/extensions/libpari.md

@@ -145,6 +145,13 @@ the value itself, in both directions — a 512-bit `t_REAL` reaches Giac with
 all 512 bits even while the ambient setting is 64, and comes back a 512-bit
 `t_REAL`.
 
+!!! warning "Linux and macOS only"
+    This section describes reals on Linux and macOS. **On Windows a real does
+    not cross at all**: a binary ABI mismatch makes the wrapper read a `_REAL`
+    tag as `_DOUBLE_`, so it arrives truncated to twelve significant digits.
+    See [Reals do not cross on Windows](@ref) before relying on any of what
+    follows.
+
 ```julia
 using Giac, LibPARI
 
@@ -179,20 +186,85 @@ by construction.
 Reading a Giac `REAL` back out is the exception, and it is worth stating
 plainly. The libgiac wrapper exposes `to_double` — a `Float64`, and therefore
 lossy — and nothing for an MPFR value; reaching past it into an undeclared
-libgiac C symbol is a call this project does not make. Giac's printer does,
-however, emit a `REAL` at that value's *own* precision rather than at a global
-setting, so the decimal it produces is faithful and only the bit width has to
-be recovered.
-
-The bridge recovers that width by search and then **verifies** it: a candidate
-is accepted only when re-encoding it reproduces Giac's own printed form
-character for character. A width that cannot be verified raises rather than
-returning a quietly-rounded value. The behaviour is pinned by tests at 64,
-128, 192, 256, 384, 512 and 1024 bits.
+libgiac C symbol is a call this project does not make. **On Linux and macOS**
+Giac's printer emits a `REAL` at that value's *own* precision rather than at
+the global `Digits` setting, so the decimal it produces is faithful and only
+the bit width has to be recovered.
+
+The bridge recovers that width by search and then re-encodes the candidate,
+accepting it only when the printed forms agree character for character. A
+width for which nothing agrees raises rather than returning a quietly-rounded
+value. The behaviour is pinned by tests at 64, 128, 192, 256, 384, 512 and
+1024 bits.
+
+Note precisely what that check does and does not establish. It tests the
+**printer's self-consistency**, not its fidelity to the stored value. Those
+coincide only where the printer is faithful — which is why the check is sound
+on Linux and macOS and blind on Windows, where it confirms a truncated answer
+without complaint. See [Reals do not cross on Windows](@ref).
 
 This would become unnecessary if the wrapper gained an MPFR accessor for
-`REAL`; until then it is the bridge's only text-mediated step, and it is
-checked rather than trusted.
+`REAL`; until then it is the bridge's only text-mediated step.
+
+## Reals do not cross on Windows
+
+**On Windows, a `t_REAL` does not survive the crossing.** Every real arrives
+truncated to twelve significant digits, whatever precision was asked for:
+
+```julia
+p = setprecision(() -> LibPARI.PARI.mppi(), LibPARI.Gen, 512)
+
+pari(to_giac(p)) == p     # false on Windows, true elsewhere
+# expected  3.1415926535897932384626433832795028842
+# obtained  3.14159265359 0000062
+```
+
+This is **not** a Giac printing quirk and not something the bridge can work
+around. It is a known ABI bug between the two binaries, already diagnosed,
+with a fix in flight upstream.
+
+`class gen` historically stored its tag as a bitfield —
+`unsigned char type:5; unsigned char type_unused:3;`. GCC fuses adjacent
+bitfield writes into one wider store and chooses the bit placement in a
+version-dependent way. `GIAC_jll` is built with GCC 8 and
+`libgiac_julia_jll` with GCC 10, so the two disagree about which bits hold
+`type`: libgiac writes a gen tagged `_REAL`, and the wrapper reads back
+`_DOUBLE_`. Giac.jl then believes it is holding a `Float64`, prints it at the
+global `Digits` — default 12 — and the extra precision is gone.
+
+That the loss is identical at 64, 128, 256, 512 and 1024 bits is the tell:
+53 bits is all a mis-tagged `DOUBLE` ever had. **Raising `Digits` would change
+nothing** — the precision is lost at the tag, not at the printer.
+
+The fix is [JuliaPackaging/Yggdrasil#13717](https://github.com/JuliaPackaging/Yggdrasil/pull/13717),
+which bumps `GIAC_jll` to v2.0.2 built with `GIAC_TYPE_ON_8BITS=1` — making
+`type` a plain byte at offset 0, so the ABI no longer depends on the compiler
+version — followed by a matching `libgiac_julia_jll` bump. Same root cause as
+[Giac.jl#22](https://github.com/s-celles/Giac.jl/pull/22) and the diagnostic
+probe in [Giac.jl#26](https://github.com/s-celles/Giac.jl/pull/26).
+
+**Everything else in the bridge works on Windows** — integers, rationals,
+complex numbers, polynomials, vectors, matrices, the refusal list, variable
+names. Only reals are affected, and a `DOUBLE` crosses correctly, since a
+`DOUBLE` is what the mis-tag claims it already is.
+
+The affected assertions are marked `@test_broken` on Windows rather than
+skipped. When the two JLLs land, those markers will start reporting
+*unexpected passes*, which is the signal to delete them.
+
+If you need reals to cross on Windows before then, convert to an exact type
+first — `Rational` crosses faithfully on every platform.
+
+### What this says about the bridge's own safety check
+
+The bridge reads a Giac `REAL` back by decoding its printed decimal, and
+verifies the result by re-encoding it and comparing printed forms. On Windows
+that check is **blind**: re-encoding the truncated value also prints twelve
+digits, the forms agree, and a wrong answer is confirmed without complaint.
+
+The check establishes the printer's *self-consistency*, not its *fidelity to
+the stored value*. Those coincide only where the tag is right. A guard worth
+having, but not one that can detect a lie told further down the stack.
 
 ## Known limitations
 
@@ -220,16 +292,23 @@ Giac.jl's suite rather than in your results.
    PARI's `t_REAL`; coming back, Giac picks `DOUBLE` or `REAL` according to
    how much precision the value needs. Values are preserved either way.
 
-4. **A `Gen` is not a `Number`.** It is a `LibPARI.PariObject`. Generic
+4. **Reals do not cross on Windows** — see the dedicated section above. A
+   `t_REAL` arrives truncated to twelve significant digits, because a GCC
+   bitfield-ABI mismatch between `GIAC_jll` and `libgiac_julia_jll` makes the
+   wrapper read a `_REAL` tag as `_DOUBLE_`. Fix in flight upstream
+   ([Yggdrasil#13717](https://github.com/JuliaPackaging/Yggdrasil/pull/13717));
+   every other type is unaffected.
+
+5. **A `Gen` is not a `Number`.** It is a `LibPARI.PariObject`. Generic
    numeric code bounded by `T<:Number` will not accept one, and `Number`
    methods must not be assumed to apply.
 
-5. **`LibPARI.PARI.gpolvar` takes a keyword**, not a positional argument:
+6. **`LibPARI.PARI.gpolvar` takes a keyword**, not a positional argument:
    `gpolvar(; x1 = g)`. Most of LibPARI's generated bindings pass the first
    argument positionally and the rest as keywords; check the signature before
    calling one.
 
-6. **`gp_eval` does not honour `setprecision(LibPARI.Gen, …)`.** It goes
+7. **`gp_eval` does not honour `setprecision(LibPARI.Gen, …)`.** It goes
    through the GP interpreter, which reads PARI's process-global
    `realprecision`, so `setprecision(() -> gp_eval("Pi"), LibPARI.Gen, 512)`
    returns a 128-bit value. This is documented, intended LibPARI behaviour —

docs/src/llms-full.txt

@@ -5422,6 +5422,13 @@ the value itself, in both directions — a 512-bit `t_REAL` reaches Giac with
 all 512 bits even while the ambient setting is 64, and comes back a 512-bit
 `t_REAL`.
 
+!!! warning "Linux and macOS only"
+    This section describes reals on Linux and macOS. **On Windows a real does
+    not cross at all**: a binary ABI mismatch makes the wrapper read a `_REAL`
+    tag as `_DOUBLE_`, so it arrives truncated to twelve significant digits.
+    See [Reals do not cross on Windows](@ref) before relying on any of what
+    follows.
+
 ```julia
 using Giac, LibPARI
 
@@ -5456,20 +5463,85 @@ by construction.
 Reading a Giac `REAL` back out is the exception, and it is worth stating
 plainly. The libgiac wrapper exposes `to_double` — a `Float64`, and therefore
 lossy — and nothing for an MPFR value; reaching past it into an undeclared
-libgiac C symbol is a call this project does not make. Giac's printer does,
-however, emit a `REAL` at that value's *own* precision rather than at a global
-setting, so the decimal it produces is faithful and only the bit width has to
-be recovered.
-
-The bridge recovers that width by search and then **verifies** it: a candidate
-is accepted only when re-encoding it reproduces Giac's own printed form
-character for character. A width that cannot be verified raises rather than
-returning a quietly-rounded value. The behaviour is pinned by tests at 64,
-128, 192, 256, 384, 512 and 1024 bits.
+libgiac C symbol is a call this project does not make. **On Linux and macOS**
+Giac's printer emits a `REAL` at that value's *own* precision rather than at
+the global `Digits` setting, so the decimal it produces is faithful and only
+the bit width has to be recovered.
+
+The bridge recovers that width by search and then re-encodes the candidate,
+accepting it only when the printed forms agree character for character. A
+width for which nothing agrees raises rather than returning a quietly-rounded
+value. The behaviour is pinned by tests at 64, 128, 192, 256, 384, 512 and
+1024 bits.
+
+Note precisely what that check does and does not establish. It tests the
+**printer's self-consistency**, not its fidelity to the stored value. Those
+coincide only where the printer is faithful — which is why the check is sound
+on Linux and macOS and blind on Windows, where it confirms a truncated answer
+without complaint. See [Reals do not cross on Windows](@ref).
 
 This would become unnecessary if the wrapper gained an MPFR accessor for
-`REAL`; until then it is the bridge's only text-mediated step, and it is
-checked rather than trusted.
+`REAL`; until then it is the bridge's only text-mediated step.
+
+## Reals do not cross on Windows
+
+**On Windows, a `t_REAL` does not survive the crossing.** Every real arrives
+truncated to twelve significant digits, whatever precision was asked for:
+
+```julia
+p = setprecision(() -> LibPARI.PARI.mppi(), LibPARI.Gen, 512)
+
+pari(to_giac(p)) == p     # false on Windows, true elsewhere
+# expected  3.1415926535897932384626433832795028842
+# obtained  3.14159265359 0000062
+```
+
+This is **not** a Giac printing quirk and not something the bridge can work
+around. It is a known ABI bug between the two binaries, already diagnosed,
+with a fix in flight upstream.
+
+`class gen` historically stored its tag as a bitfield —
+`unsigned char type:5; unsigned char type_unused:3;`. GCC fuses adjacent
+bitfield writes into one wider store and chooses the bit placement in a
+version-dependent way. `GIAC_jll` is built with GCC 8 and
+`libgiac_julia_jll` with GCC 10, so the two disagree about which bits hold
+`type`: libgiac writes a gen tagged `_REAL`, and the wrapper reads back
+`_DOUBLE_`. Giac.jl then believes it is holding a `Float64`, prints it at the
+global `Digits` — default 12 — and the extra precision is gone.
+
+That the loss is identical at 64, 128, 256, 512 and 1024 bits is the tell:
+53 bits is all a mis-tagged `DOUBLE` ever had. **Raising `Digits` would change
+nothing** — the precision is lost at the tag, not at the printer.
+
+The fix is [JuliaPackaging/Yggdrasil#13717](https://github.com/JuliaPackaging/Yggdrasil/pull/13717),
+which bumps `GIAC_jll` to v2.0.2 built with `GIAC_TYPE_ON_8BITS=1` — making
+`type` a plain byte at offset 0, so the ABI no longer depends on the compiler
+version — followed by a matching `libgiac_julia_jll` bump. Same root cause as
+[Giac.jl#22](https://github.com/s-celles/Giac.jl/pull/22) and the diagnostic
+probe in [Giac.jl#26](https://github.com/s-celles/Giac.jl/pull/26).
+
+**Everything else in the bridge works on Windows** — integers, rationals,
+complex numbers, polynomials, vectors, matrices, the refusal list, variable
+names. Only reals are affected, and a `DOUBLE` crosses correctly, since a
+`DOUBLE` is what the mis-tag claims it already is.
+
+The affected assertions are marked `@test_broken` on Windows rather than
+skipped. When the two JLLs land, those markers will start reporting
+*unexpected passes*, which is the signal to delete them.
+
+If you need reals to cross on Windows before then, convert to an exact type
+first — `Rational` crosses faithfully on every platform.
+
+### What this says about the bridge's own safety check
+
+The bridge reads a Giac `REAL` back by decoding its printed decimal, and
+verifies the result by re-encoding it and comparing printed forms. On Windows
+that check is **blind**: re-encoding the truncated value also prints twelve
+digits, the forms agree, and a wrong answer is confirmed without complaint.
+
+The check establishes the printer's *self-consistency*, not its *fidelity to
+the stored value*. Those coincide only where the tag is right. A guard worth
+having, but not one that can detect a lie told further down the stack.
 
 ## Known limitations
 
@@ -5497,16 +5569,23 @@ Giac.jl's suite rather than in your results.
    PARI's `t_REAL`; coming back, Giac picks `DOUBLE` or `REAL` according to
    how much precision the value needs. Values are preserved either way.
 
-4. **A `Gen` is not a `Number`.** It is a `LibPARI.PariObject`. Generic
+4. **Reals do not cross on Windows** — see the dedicated section above. A
+   `t_REAL` arrives truncated to twelve significant digits, because a GCC
+   bitfield-ABI mismatch between `GIAC_jll` and `libgiac_julia_jll` makes the
+   wrapper read a `_REAL` tag as `_DOUBLE_`. Fix in flight upstream
+   ([Yggdrasil#13717](https://github.com/JuliaPackaging/Yggdrasil/pull/13717));
+   every other type is unaffected.
+
+5. **A `Gen` is not a `Number`.** It is a `LibPARI.PariObject`. Generic
    numeric code bounded by `T<:Number` will not accept one, and `Number`
    methods must not be assumed to apply.
 
-5. **`LibPARI.PARI.gpolvar` takes a keyword**, not a positional argument:
+6. **`LibPARI.PARI.gpolvar` takes a keyword**, not a positional argument:
    `gpolvar(; x1 = g)`. Most of LibPARI's generated bindings pass the first
    argument positionally and the rest as keywords; check the signature before
    calling one.
 
-6. **`gp_eval` does not honour `setprecision(LibPARI.Gen, …)`.** It goes
+7. **`gp_eval` does not honour `setprecision(LibPARI.Gen, …)`.** It goes
    through the GP interpreter, which reads PARI's process-global
    `realprecision`, so `setprecision(() -> gp_eval("Pi"), LibPARI.Gen, 512)`
    returns a 128-bit value. This is documented, intended LibPARI behaviour —