salvage.c: In function 'corrupt':
salvage.c:91:2: error: conversion to 'long unsigned int' from 'off_t'
may change the sign of the result [-Werror=sign-conversion]
salvage.c:91:22: error: conversion to 'off_t' from 'long unsigned int'
may change the sign of the result [-Werror=sign-conversion]
salvage.c:92:21: error: comparison between signed and unsigned integer
expressions [-Werror=sign-compare]
salvage.c:92:49: error: signed and unsigned type in conditional
expression [-Werror=sign-compare]
salvage.c:92:3: error: conversion to 'long unsigned int' from 'off_t'
may change the sign of the result [-Werror=sign-conversion]
Don't increment the record number until after reviewing the record,
otherwise we might choose the wrong record (not part of the test case,
found by inspection).

When I switch the overflow tracking code recently, I introduced a bug
in column store where we'd not check overflow records when we should,
and vice-versa, this was found by the test case.
If we have "missing" records flagged by salvage, and we're not skipping
records from the page, and the first record we're taking from the page
is a "delete", we have to merge them, otherwise the RLE count won't be
optimal and verify will complain.
We can overwrite the first block when corrupting the file, force the
salvage so that's ignored.
Shuffle some code for clarity and to make lint happy (no real change).
We can't split during salvage: first, turn off raw compression (because
we can't control when/where raw compression chooses to split), and then
choose a page size which guarantees we won't need to split.  Ref #1190.
Unused variable.
One more time, this function doesn't return an error (and I don't see any
particular value in making it return an error), I'm only calling it from
the leaf-page functions.
src/btree/rec_write.c:3238:182: error: implicit conversion loses integer precision: 'unsigned long' to 'uint32_t'
If we fail to acquire a block during salvage (in this case because
the decompression of the block failed), free the block immediately.
Issue #1191.
94e8052 wasn't right either: we need any overflow item appearing in the
range, so increment the record number before the test, but don't compare
against the stop recno in the test, do that afterward.  In other words,
if we're past "start", then we need to record, and if we're past stop,
we quit looking.
Copy the corrupted file before salvaging it, the dd command to
reproduce the corruption is too painful to build every time I
want to debug one of these.
One more try to get the range check for overflow records correct.
Decrement the RLE *before* setting the number of skip items to 0.
Forward declarations of enumerated types is a gcc extension, we don't
need to do it anyway.
clang complaint: bt_curprev.c:83:6: warning: variable 'ins' may be
uninitialized when used here [-Wconditional-uninitialized]
clang complaint: rec_split.c:1023:16: warning: variable 'parent' may be
uninitialized when used here [-Wconditional-uninitialized]
clang complaint: rec_write.c:2141:15: warning: variable 'result_len' may
be uninitialized when used here [-Wconditional-uninitialized]
clang complaints for unconditionalized variables; I don't believe either are
a real problem, flag them as compiler warnings.
Flag the change as a compiler warning, I don't think it's a real problem.