Make sure that each va_start has one and only one matching va_end,
especially in error cases.
If the va_list is used multiple times, do multiple va_starts/va_ends.
If a function gets va_list as argument, don't let it use va_end (since
it's the callers responsibility).
Improved by comments from enami and christos -- thanks!
Heimdal/krb4/KAME changes already fed back, rest to follow.
Inspired by, but not not based on, OpenBSD.
aggressive; rework to be a bit less susceptable to round-off error.
now it's likely that the density might not be obtained with a small
filesystem with a large number of inodes (e.g -s 4M -i 1k), but that's
an extremely unlikely corner case that can easily be rectified with
command-line arguments.
fixed provided in private email by Takao Shinohara <shin@sm.sony.co.jp>
should resolve PRs [bin/14049] and [bin/14046]
1) Always do a make clean before building objects in any directory. This
is wasteful, but there's really no other simple way to cope with the
fact that the compilation settings (e.g. CFLAGS) appropriate for the
non-crunched build of a program may not be appropriate for the crunched
build. If the objdir magic in make didn't rely upon the presence of an
"obj" or "obj.${MACHINE}" symlink, we could abuse it to handle this but
unfortunately, it does.
2) Override $DBG to cause object files to be built with -Os. We can't emit
"DBG?=" into the generated makefile because of order-of-inclusion issues
with the system Makefiles; the result would be that the default setting
(currently -O2) would always be used instead of -Os. If you're crunching,
you almost certainly are doing it to get a smaller executable (!) so -Os
is almost certainly appropriate for you.
1) If a password entry is of the form \*[A-z-]+, do not complain that
the account is off but has a valid password. Thus you can do
passwords like *ssh to indicate ssh only logins.
We should come up with a standard scheme for what various *keywords mean.
Note that if the field length is 13, 20 or 34 you'll still get
bitched at.
This code should be cleaned up. (So should the password scheme.)
2) If the entry is for "toor", don't complain that the account is off
but has a valid shell. We ship with toor:*:, there is no point in
complaining about it.
Part of the campaign against spurious security warning output.
