Subject: Re: types gone amuck (Re: CVS commit: basesrc/bin/pax)
To: Chuck Silvers <chuq@chuq.com>
From: Klaus Klein <kleink@reziprozitaet.de>
List: tech-kern
Date: 10/27/2001 18:09:57
Chuck Silvers <chuq@chuq.com> writes:

> 	(void)snprintf(buf, size, "%lu secs (" OFFT_F " bytes/sec)",
> 	    (unsigned long)tm, (OFFT_T)(sz / tm));
> 
> where we have:
> 
> #define	OFFT_F			"%llu"
> #define	OFFT_T			u_longlong_t
> 
> 
> the reason this is a problem is:
> /build/destdir/usr/include/sys/types.h:typedef  u_quad_t        u_longlong_t;   /* ANSI unsigned long long type */

Now that comment is an interesting concept. :-)

> so the way things are right now, we can't assume that "u_longlong_t"
> is equivalent to "unsigned long long".  so the question is:
> is "u_longlong_t" just supposed to be an unsigned 64-bit type,
> or is it supposed to be equivalent to "unsigned long long"?

With the principle of least surprise in mind, I believe it is supposed
to be the latter but was usually used under the assumption of being
the former.

Anyway, referring to the original change, I don't quite see the point
of using a system-provided *longlong_t here; in the same place use is
made of ULLONG_MAX and strtoll(), both being C99 features, so it's
curious to see its "long long int" types not being used.


- Klaus