Subject: Re: types gone amuck (Re: CVS commit: basesrc/bin/pax)
To: Chuck Silvers <email@example.com>
From: Klaus Klein <firstname.lastname@example.org>
Date: 10/27/2001 18:09:57
Chuck Silvers <email@example.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
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.