[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recent checkins

From: Thomas Bushnell, BSG
Subject: Re: Recent checkins
Date: 08 May 2002 15:22:33 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Roland McGrath <roland@gnu.org> writes:

> > MiG interfaces must be the *SAME* bit widths on all platforms.  That
> > is, a MiG integer_t is 32 bits and must be 32 bits on *every*
> > architecture.
> That is not true at all.

Um, so can you elucidate?

A sample RPC is, say, file_chauthor.

That RPC has two arguments.  One is the recipient, which must have
type MACH_MSG_TYPE_COPY_SEND.  The other is the new author ID, which
must have type MACH_MSG_TYPE_INTEGER_32.  The actual file_chauthor
spec refers to uid_t, but:

<hurd/hurd_types.defs> has
  type uid_t = int

<mach/std_types.defs> has
  type int = MACH_MSG_TYPE_INTEGER_32

Now, if that latter type were changed on some platform, then we would
get an inconsistent wire protocol between that platform and the one
we're on.  If there were a bijection between different integer types,
this would not be a problem; the net msg server could map the types.
Such can be done to deal with endianness, but not with length.

If alpha Mach has


then we have a bug, and the right fix is probably to stop using names
like "short" and "int" in MiG, and instead use the names with explicit


reply via email to

[Prev in Thread] Current Thread [Next in Thread]