Bug report: filemap reporting has side-effects on masters Bloom filter

[ncanceill]

• Status: Present in original implementation
• Description: call to print_report() has side-effect on masters_t::NSRLBloom.
• Reproduce: Use the program twice, with and without the -r option, and witness the "Total number of bloom filter hits" output change; the -roption triggers an additional call to (*t)->print_report(0,blocksize).
• Fix: ???

Working on it atm, standby...

[ncanceill]

Seems it comes from a side-effect of lazy evaluation in the add_block_hash() function, because an additional query is sent to the bloom filter in order to check for previous appearance.

    if(opt_raw && b.query(md5.digest)){
    cout << "Input file block " << blocknumber << "appears previously at ";;
    for(blocklist_t::const_iterator i = this->md5map[md5].begin();
        i!=this->md5map[md5].end();
        i++){
        printf("%"PRId64" ",*i);
    }
    printf("\n");
    }

Side-effect occurs in the nsrl_bloom_query() function because it increments hits upon each query.

    /* All of the bits were set; hash must be in the bloom filter */
    if(b->debug>1) putchar('\n');
    b->hits++;

[ncanceill]

Extending API by pseudo-overloading seems to work, waiting for simsong/frag_find#1 to be pulled first.