/bin/sort

[utzoo!decvax!ucbvax!unix-wizards]

>From chico!harpo!chico!eagle!jpl at Berkeley Tue Sep 15 15:13:03 1981
A letter from Peter Weinberger called my attention to the fact that a
sort misfeature which I thought had been corrected 2 years ago is still
alive and well and infecting Berkeley UNIX as well as Bell Labs variants.
This particular misfeature (there are many) will show up on any machine
for which sizeof(char *)/sizeof(char) != 2.  It does not prevent sort
from working, it merely causes it to underutilize the memory it allocates,
leading to more sort temporary files, leading to longer sort times.

The source of the problem is in the memory management initialization

   nlines = (a - L);
   nlines /= (5*(sizeof(char *)/sizeof(char)));
   ntext = nlines*8;

I assume (comments are rare in the source) that the intent is dedicate
1/5 of the memory which has just been allocated to pointers to records,
and the remaining 4/5 to the records themselves.  (The L is slop space
for the last record in a coreload -- more about it later.)  The effect
is to set nlines to the number of pointers which will fit in 1/5 of the
available space, but that funny magic number 8 is a throwback to the
days of 2-byte pointers.  It might better read,

   ntext = nlines * 4 * (sizeof(char *)/sizeof(char));

lest, on vaxen, half the record space will be unused.  If you run a big
sort on a vax and an 11, you can see that the sort temporaries on the
vax are only about 1/2 the size of those on the 11.  The ``good news''
is that the wasted space gives added protection against reading a big
record (>L bytes) when memory is nearly full and writing all over
critical memory, generally leading to a core dump.

While you're in there changing the sort, take the time to make blank()
a macro, like

#define blank(c) ((c==' ')||(c=='\t'))

On sorts with arguments (sort -t: +6 -7 /etc/passwd), up to 50% of
the cpu time can be gobbled up by the blank routine.

    May all your disorders be temporary.
    John P. Linderman  eagle!jpl