gcc always generates large code for accesses to globals. For locals
it only generates large code if there are more than 128 bytes of
locals. It sorts scalar locals after array locals to pessimize for
space in the usual case when there are more (static) references to
scalars than to arrays.
Saved another 16 bytes (13 before padding) by adding a `continue'.
Fall-through tests normally save space, but here one of them made
gcc do space-unoptimal register allocation (it allocates ch in %bl
because preserving this register across function calls is "free",
but comparisions with %bl take one byte fewer than comparsions with
%bl).
- add ctm_conf.gnats from freefall
- add support for doing both the immediate mailout and the queued mailout.
- use "sendmail -odq -t" rather than "sendamil -t" to make it queue to
the mailqueue rather than immediately begin transmission. This allows
us to take advantage of our ordered dequeueing system without blowing
WC's T1 to hell with a 50 part mailout in parallel.
- bump the max ctm size from 3MB to 10MB.... This is mainly for the fast
list.
for entire SYS5 SHM segments. This is totally unnecessary, and so the
correct allocation of VM objects has been substituted. (The vm_mmap
was misused -- vm_object_allocate is more appropriate.)
we actually look for the *group* and not the user's gid. user daemon
has traditionally been group 31 (guest).
Also clear out the groups vector so that it doesn't inherit the groups
of the invoking user (ever run rwhod by hand before?) Unfortunately, we
can't empty the supplemental groups list because the !&@^#! egid is stored
in there! :-(
negated the descriptive sense of "frag" and "-N", which were clearly wrong.
changed instructions (which were bogus in the extreme) for allowing/preventing
outgoing rsh/rlogin, rewording the paragraph so it applies to incoming
connections so it actually both makes sense and tells the truth. It can
be deleted instead if not relevant.
did not change the paragraph about loading multiple rules in one command,
although this operation is now partially supported by loading from a
command file.
I hope I'm not treading on anyone's toes here.
If you define this, it means your keyboard is actually probable using the
brain-dammaged probe routine in syscons, and if the keyboard is NOT found,
then you don't want syscons to activate itself further.
This makes life sane for those of us who use serial consoles most of the
time and want "the right thing" to happen when we plug a keyboard in.
of connections, we cannot afford to allow "disappeared" client to cause
us to leave one of the 14 connections open and hanging in a read() forever.
(SO_KEEPALIVE causes probe packets to be sent after a few hours of IDLE
time where no data has been transferred. Sup should NEVER do this, so the
only time it will have an effect is if it looses the remote machine)
files in /var/tmp. Sup needs to send the file size, so that
prevents running gzip in a pipeline (sigh).
It now opens a temporary file, and immediately unlinks it. It sends
gzip's output to the temp file, and when gzip is done, it rewinds the
file and sends it. When the last fd is closed, the file storage is
reclaimed. With luck, this will stop those 15MB
gzip < emacs-19.30.tgz > /var/tmp/tmp.xxxx files from being left behind
and blowing out /var on freefall.
While I have the platform, let me quote a fortune entry which sup reminds
me of: "It is a crock of sh!t, and it stinks!"
of copies to save is zero. Incorporate suggested fix with some stylistic
cleanup to make the resulting code more readable.
Submitted-By: Kenneth Stailey <kstailey@dol-esa.gov>
as a PR to GNATs but it evidently went astray somehow since I can't find
it in the database now, nor does an assigned PR# appear on the mail I got.
Sorry about that, Danny!
Submitted-By: Danny R. Johnston <danny@simn.com>
Bowrite guarantees that buffers queued after a call to bowrite will
be written after the specified buffer (on a particular device).
Bowrite does this either by taking advantage of hardware ordering support
(e.g. tagged queueing on SCSI devices) or resorting to a synchronous write.
Bowrite guarantees that buffers queued after a call to bowrite will
be written after the specified buffer (to a particular device).
Bowrite does this either by taking advantage of hardware ordering support
(e.g. tagged queueing on SCSI devices) or by resorting to a synchronous write.
