Subject: Re: types gone amuck (Re: CVS commit: basesrc/bin/pax)
To: Klaus Klein <firstname.lastname@example.org>
From: Luke Mewburn <email@example.com>
Date: 10/28/2001 23:31:26
On Sat, Oct 27, 2001 at 06:09:57PM +0200, Klaus Klein wrote:
> Chuck Silvers <firstname.lastname@example.org> 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 ?