svn commit: r209567 - head/usr.bin/lock

[Bruce Evans]

On Mon, 28 Jun 2010, Gavin Atkinson wrote:

> Log:
>  Make WARNS=6 safe.

This mainly breaks the warning.

> Modified: head/usr.bin/lock/lock.c
> ==============================================================================
> --- head/usr.bin/lock/lock.c	Mon Jun 28 08:10:55 2010	(r209566)
> +++ head/usr.bin/lock/lock.c	Mon Jun 28 08:30:10 2010	(r209567)
> @@ -65,6 +65,7 @@ __FBSDID("$FreeBSD$");
> #include <ctype.h>
> #include <errno.h>
> #include <pwd.h>
> +#include <stdint.h>

Include to support bogusness below.

> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> @@ -257,9 +258,9 @@ hi(int signo __unused)
> 		if (no_timeout) {
> 			(void)putchar('\n');
> 		} else {
> -			(void)printf("timeout in %ld:%ld minutes\n",
> -			    (nexttime - timval.tv_sec) / 60,
> -			    (nexttime - timval.tv_sec) % 60);
> +			(void)printf("timeout in %jd:%jd minutes\n",
> +			    (intmax_t)(nexttime - timval.tv_sec) / 60,
> +			    (intmax_t)(nexttime - timval.tv_sec) % 60);

Printing time differences using intmax_t is silly.  They don't need to
work for more than a few days here, but even casting to 16-bit ints
lets them work for 32767 minutes = 546 hours here, while the natural
casts here (of timeval.tv_sec to long) lets them work for 65536 times
longer than that = 4082 years even with 32-bit longs.

Any casts here risk breaking the warnings about type mismatches and
resulting overflows, and in fact there are many in this program.  Here
there is just the promotion of timval.tv_sec to time_t causing the
printf args to normally not match the printf format.  Elsewhere there
are overflow bugs caused by incomplete conversion to time_t, and worse.
Mainly here:

% 	nexttime = timval.tv_sec + (sectimeout * 60);

This has about 10 style, type mismatch and overflow bugs, counting other
bugs involving sectimeout, starting with sectimeout not actually being the
seconds timeout (it is the minutes timeout, and scaling it to a seconds
timeout gives overflow bugs).  If the program gets this far without
triggering the bugs, then it has few risks of more, since the residual
timeout is <= the original timeout which must be small to work.

Bruce