foo += sscanf(++foo, ...);
constructs to:
++foo;
foo += sscanf(foo, ...);
to avoid the following warning from gcc 3.1:
warning: operation on `pos' may be undefined
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.
For some reason this program wants to open _hundreds_ of temporary files.
Make it setrlimit(RLIMIT_NOFILE, ...), so this rather dubious strategy at
least works well enough to ctag(1) our own kernel.
XXX
path buffer
- provide better error messages about why the temp file creation is failing
- explicitly compare syscall return to -1 instead of < 0 and fdopen return
to NULL instead of 0.
If no output file was specified sort fopened("/dev/stdout", "w").
This is *wrong* because "/dev/stdout" will truncate the output file,
thus undoing the append effect the shell had set up. The simple fix
here is to just arrange for outfp = stdout and don't play with /dev/stdout.
While I am here:
- KNF
- make pattern for mkstemp have 6 X's.
whitespace changes, which don't influence the layout of result manpage at all,
but also add -H to SYNOPSIS and state sort(1) appeared in v5, not v6 of
AT&T Unix.
branch, since we might get called with tablepos == endkey for some special
input files (where an record would happen to fit exactly to the input
buffer) - BTW, this bug looks like it has been here ~forever ...
This seems to fix the sort crash for 'make british' build of ispell package,
as reported by Mark White at current-users@.
enlarge them as necessary to read records from merged files; the buffers
are allocated once per program run, so there shouldn't be any
performance difference
This makes sort(1) pass also regression 40B and should make it
fully arbitrary long record capable.
XXX the buffer array could probably be freed on end of fmerge() to save memory
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()
