actually read already. Albeit it's not damaging to copy zero data
for bufend == crec->data case, the buffer end could also be between
memory position 'crec' and 'crec->data'. Thus, we could end up with
negative 'bufend - crec->data' value, and obvious havoc.
This change fixes lib/12673, though the problem was masked and no longer
repeatable with the provided example after the recent buffer size bump.
The change was tested with the buffer size change backed off, and really
fixes the problem in the PR.
if needed and record count is within bounds (<MAXNUM), rather than
sorting the input by 64KB chunks. This cuts the number of needed
temporary files considerably (and improves performance, too).
Slighly adjust some #defines, mostly to power of 2 values.
This addresses bin/12673 and bin/12614, as well as complains from other
people.
excessive number of temporary files for oversized records; the way the
buffer is enlarged is now also safer
initialize 'bufsize' statically, so that the value can be safely used
in e.g. msort.c:fmerge()
* get rid of union f_handle, replace by passing explicit int parameter
and (new) struct filelist
* add new typedefs gen_func_t and put_func_t and use where appropriate
'offset' members of struct recheader/trecheader are shorts - they are size_t
now
this makes sort pass all tests in TEST/stests again after my last change
other misc cosmetic changes
