fix rawbigints

[nsajko]

Using Ptr like that was incorrect. Among other issues, a Ptr doesn't own the data it points to, so hold a String instead.

Fixes #51111

[nsajko]

There's significant performance degradation for Float64 in particular, so I'll add some @inbounds.

[nsajko]

Ended up removing the boundschecking altogether. It seemed simpler than sprinkling @inbounds all over, and the lack of bounds checking for rawbigints didn't seem to cause any bugs anyway.

[nsajko]

Regarding the needs tests label, my current minimal reproducer for #51111 is:

using StochasticRounding, OrdinaryDiffEq
const SR = Float32sr
OrdinaryDiffEq.Tsit5ConstantCacheActual(SR, SR)

To make it amenable for inclusion into Julia's test suite, it would be necessary to get rid of the two package dependencies. This seems like it would be quite time consuming, while risking ending up with a huge reproducer in the end.

I tried to remove the dependency on OrdinaryDiffEq, with minimal changes, and ended up with a non-reproducer in the process. So what I'm trying to say is, this is (I guess so, at least) a difficult-to-reproduce heisenbug caused by undefined behavior, is it really worth it trying to add a test here?

[maleadt]

Regarding the needs tests label, my current minimal reproducer for #51111 is:

using StochasticRounding, OrdinaryDiffEq
const SR = Float32sr
OrdinaryDiffEq.Tsit5ConstantCacheActual(SR, SR)

Why not the MWE I reduced it to? There's a couple of tests that require separate packages already, so you could mimic what they do.

[vtjnash]

LGTM. There should be similar tests in precompile. There is already a abigfloat_x value, it looks like you just need to add some code to exercise this path (whereas currently it only tests addition).

[nsajko]

Added the test based on the MWE by @maleadt to the location suggested by @vtjnash. Thanks.

Why not the MWE I reduced it to?

I misunderstood your MWE back then and thought I couldn't reproduce the issue using it.