kern/68081: [headers] [patch] sys/time.h (lint fix)

Bruce Evans brde at optusnet.com.au
Tue Jul 29 04:48:46 UTC 2008


On Mon, 28 Jul 2008, John Baldwin wrote:

> The following reply was made to PR kern/68081; it has been noted by GNATS.
>
> From: John Baldwin <jhb at FreeBSD.org>
> To: bug-followup at FreeBSD.org, cyrille.lefevre at laposte.net
> Cc:
> Subject: Re: kern/68081: [headers] [patch] sys/time.h (lint fix)
> Date: Mon, 28 Jul 2008 17:27:38 -0400
>
> You have to use 'lint -a' in which case you get 2 of the warnings:
>
> > lint -a stupid.c
> stupid.c:
> time.h(112): warning: conversion from 'unsigned long long' may lose accuracy
> [132]
> time.h(129): warning: conversion from 'unsigned long long' may lose accuracy
> [132]
> _types.h(60): warning: struct __timer never defined [233]
> _types.h(61): warning: struct __mq never defined [233]
> ...
>
> However, I'm not sure it is worth adding casts to appease optional behavior of
> lint when there is no actual bug.

But there is an actual bug.  It is that lint is stupid.  It would be of
negative worth to add casts to appease this bug.

> (The number of micro-seconds in a partial
> second is always going to fit into a 32-bit value.)

Not just that.  Lint cannot tell that the values are within bounds for a
microsecond or a nansecond.  However, the values are of the form

 	((uint64_t)N * v) >> 32

where v is a 32-bit value and N is not too large (slightly less than 1/4 of
UINT32_MAX in the worst case).  Thus the final value is slightly less than
1/4 of UINT32_MAX in the worst case so it fits in an an int32_t, and on
the target machine the target type happens to be int == int32_t.

Lint is also too stupid to issue this warning in some cases where
conversion loses accuracy.   It fails to warn for conversion from long
to int when run on i386.  There is no problem on i386, but there is
on machines where long is actually long (so that it is longer than
int).  It fails to warn for conversion from u_int to int (this may
lose the sign bit, and the loss is unrecoverable on exotic machines).

I think gcc now does enough static analysis to give useful warnings here
(i.e., none in time.h, but one for the above expression without the
right-shift by 32).

Bruce


More information about the freebsd-bugs mailing list