Comment 4 for bug 2028575

The observable facts contradict this baseline assumption. The only things I can be certain of are that the relevant behaviour is implementation-dependent (the bug only appears in SBCL on any platform) as well as inconsistent by platform (special steps had to be taken to reproduce the bug on a proper subset of supported platforms), because the bug in question did not appear on macOS even after adopting the full configuration parameters of the user reporting the issue, but was immediately reproduced exactly as reported on Linux and Windows. I was able to reproduce the bug on macOS as reported by changing only one line of code: removing the local declaration. This led me to discover the implementation-dependent behaviour of safety, and the rest is pretty much already stated above.

If you'd like a better test case, we can always step back to CL-ISAAC 1.0.7 where the issue is apparent, reproduce the variance by platform, and reanalyze the problem against other Lisp implementations. Other underlying issues may be at play, such as SBCL's internal representation of integers that "overflow" as far as the ISAAC-32 and ISAAC-64 algorithms are concerned, but don't in any other Lisp. That was the source of the type-error bug reported to me by the user, which was already pretty weird considering every other Lisp appeared to be correctly generating 32 and 64 bit integers at that step, but even if they did "overflow" that's what the LOGAND is for, as the modulus. I was going to report this as a separate bug. I've amassed quite a long list of issues I need to report, which I've put off long enough.

Alternatively, I can keep trying to correctly characterize and fix this issue all on my own. I've forked the official mirror of SBCL on GitHub to start the process of contributing, but would appreciate any clarity you can offer on what I can do to support the established workflow.

For the sake of clarity, but tangential to the Issue:

My strategy for bug-testing is based on delta debugging using Abductive Reasoning and Model Theory for my empirical method. I'm well aware that most of the hypotheses generated by abductive inference are going to be nonsense. The intent is to generate enough hypotheses to close the problem space, in the process eliminating irrelevant factors and uncovering hidden variables until the correct system is isolated for the solution space. For most situations this strategy is overkill, so I apply it loosely, relying on experience to decide the granularity. For this situation, it got me to a fix pretty quickly, but feels like an intractable method for the real underlying issue, whatever that might be.

You and I both know from personal experience that compilers are the single most difficult pieces of software to write, maintain, and contribute to. You've been an SBCL maintainer for as long as I can remember. I wrote my first compiler when I was 13, and most recently at my erstwhile start-up Black Brane, a whole framework for language and platform agnostic quantum compilation, as well as quantum variants of Forth, Lisp, and Prolog built on this framework. Basically LLVM for quantum computing.

I'd much rather be working on open-sourcing all my work at Black Brane, but if I can't get my code to run in SBCL, even though it compiles, loads, and runs perfectly in every other Lisp implementation, there's not much point in open-sourcing it, is there?

Back to the Issue:

I get where you're coming from and what you're trying to say, but from my experience writing language and platform agnostic compiler frameworks and digging through the SBCL source, I estimate the actual odds in this case are between 12 and 13% which is well above statistical insignificance. But I'm happy to be proven wrong.