On Sat, Oct 27, 2001 at 06:09:57PM +0200, Klaus Klein wrote:
> 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.

I only used "u_longlong_t" instead of "unsigned long long [int]",
because the latter is less to type.

Would you rather I change pax so that:
	a) it uses unsigned long long instead of u_longlong_t, or
	b) fix the port with the uncommon definition for u_long_long ?

Luke.