Subject: Re: types gone amuck (Re: CVS commit: basesrc/bin/pax)
To: Klaus Klein <>
From: Chuck Silvers <>
List: tech-kern
Date: 10/30/2001 21:26:09
so I grep'd for longlong_t in the entire source tree, and here's what I got:

include/rpc/xdr.h:extern bool_t	xdr_hyper	__P((XDR *, longlong_t *));
include/rpc/xdr.h:extern bool_t	xdr_u_hyper	__P((XDR *, u_longlong_t *));
include/rpc/xdr.h:extern bool_t	xdr_longlong_t	__P((XDR *, longlong_t *));
include/rpc/xdr.h:extern bool_t	xdr_u_longlong_t __P((XDR *, u_longlong_t *));
lib/libc/include/namespace.h:#define	xdr_longlong_t		_xdr_longlong_t
lib/libc/include/namespace.h:#define	xdr_u_longlong_t	_xdr_u_longlong_t
lib/libc/rpc/xdr.c: * NOTE: xdr_hyper(), xdr_u_hyper(), xdr_longlong_t(), and xdr_u_longlong_t()
lib/libc/rpc/xdr.c:	longlong_t *llp;
lib/libc/rpc/xdr.c:	u_longlong_t *ullp;
lib/libc/rpc/xdr.c: * XDR longlong_t's
lib/libc/rpc/xdr.c:xdr_longlong_t(xdrs, llp)
lib/libc/rpc/xdr.c:	longlong_t *llp;
lib/libc/rpc/xdr.c: * XDR u_longlong_t's
lib/libc/rpc/xdr.c:xdr_u_longlong_t(xdrs, ullp)
lib/libc/rpc/xdr.c:	u_longlong_t *ullp;
sys/sys/types.h:typedef	quad_t		longlong_t;	/* ANSI long long type */
sys/sys/types.h:typedef	u_quad_t	u_longlong_t;	/* ANSI unsigned long long type */

having the xdr_{,u_}longlong_t functions take an argument that is not a
{,u_}longlong_t would be a bit odd.  so perhaps the best thing to do
would just be to replace the comments about them being ANSI with
something like:

 * The types longlong_t and u_longlong_t exist for use with the
 * Sun-derived XDR routines involving these types, and their usage
 * in other contexts is discouraged.  Further note that these types
 * may not be equivalent to "long long" and "unsigned long long",
 * they are only guaranteed to be signed and unsigned 64-bit types
 * respectively.  Portable programs that need 64-bit types should use
 * the ANSI types int64_t and uint64_t instead.

how does that sound?


On Sun, Oct 28, 2001 at 06:32:33PM +0100, Klaus Klein wrote:
> Chuck Silvers <> writes:
> > so is "u_longlong_t" actually an ANSI-specified type?
> > if not, we should remove the comment that says that it is.
> > if it's supposed to be defined as "unsigned long long",
> > then we should change the header so that it is.
> I concur.
> > actually if this type isn't specified by any standard,
> > it may be best to just remove it.
> Of all recent systems I've seen only Solaris defining it, so except
> for cruft^H^H^H^H^Hbreakage in our own tree which we can fix, I'm all
> for it.
> - Klaus