I haven't been able to get a different result by changing printing. One thing that printing might do, however, is assign `eq?`-based hash codes to objects that did not already have them. That assignment, in turn, could affect the order in which objects appear later in a hash table.
I hacked Racket to make the internal hash-code generator count down instead of up, and I was able to get a different result that way. Are you using `eq?`-based hashing at all? Could there be some dependency on the order of values within a hash table (or hash set)? At Tue, 27 Aug 2013 14:02:50 -0400 (EDT), "J. Ian Johnson" wrote: > This is mostly an mflatt-only problem. > > My analysis framework is now using a generic dictionary for its abstract > heap, > and depending on whether or not I pretty-print this heap before continuing on > analyzing, the result of the analysis changes (sound versus unsound). I found > the problem doing some printf debugging, and when fixed, I tried removing the > print statements. The answer changed. There must be some problem in the C > code > somewhere, because this is just bonkers. > > (Note: I've had previous bugs where rewriting a (begin (void) e) => e caused > a > similar value-changing bug. Updating the compiler to head fixed it at that > point. I'm running yesterday's HEAD now, though.) > > https://github.com/dvanhorn/oaam/tree/thocon > > See the ;; mflatt: comment in code/kcfa.rkt > > To see the problem, > racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch > > Thanks, > -Ian > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev